LPCTSTR is only relevant in the source code of a C/C++ program. It equates to either LPCWSTR or LPCSTR depending on whether UNICODE is defined or not (set in the General tab of project properties). So you need to contact the originators of the code to find out whether they built it for Unicode or not.
Richard, I spent a long time on the phone to Siemens in the UK. After many attempts I managed to home in on a building that knows what I want to do but not being involved in SDKs the best they could say is they'll pass my details to an SDK group in Germany. So, you can see the problem dealing with a huge company where people have heard but don't know who from or where to go. The SDK provides a DLL which they say can only be used in C++. The OCX is intended for everything else. Unfortunately, it's a poorly documented manual. I mean it's good that they describe the protocol but there are too many loose ends of which the method declarations is but one.
Another thing I don't know is do I need to append a \0 to the strings or does VB6 do that automatically? To make it even more frustrating, I've looked at just about every online reference to BAPSI (Siemens' protocol) and I can't find a single documented sample program which might help. So, I might be guilty of passing in parameters which are not compatible and which the device can only throw away as unusable/unrecognisable.
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
That really is very poor from their side. The only other suggestions I can offer are to look at Dependency Walker[^], a tool for showing all the public elements of a DLL, and this MSDN page[^] on decorated names. These two together may be able to help you figure out what the actual SDK calls should be.
Now when I run the program only then it correctly writes into the HKEY_CURRENT_USER\\MICROSOFT\\SOFTWARE. But when I include this program as an assembly in the setup it writes into the HKEY_USERS with no entry in HKEY_CURRENT_USER. Now my problem is that the program which is supposed to access the registry data is programmed to read from HKEY_CURRENT_USER using the command
Thanks a lot for your response. I have got the reason. Thanks for the tips. It is because though the user has administrative Privileges but still I think the Setup needs to be run as Administrator. Once I did this, it has now written inot HKEY_Current_User.
Your program isnt the only one running, so you cant know when exactly youll get the thread proccessed. And the time could vary from comuter to computer, however you can give it a higher priority, but than you'll get other problems...
The easiest thing is to get the time stamp from the physical device, if it is that important.
Do take in account that you're not guaranteed to get CPU-time every 200ms. If it must react to each event of the device, the best path would be to write a device-driver. That would take you beyond VB though.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
Last Visit: 13-Dec-18 10:48 Last Update: 13-Dec-18 10:48