That's not true. You can develop eVB programs for the PocketPC. It's just a matter of the right SDK and off you go. However the eVB is a subset of the VB language and doesn't support many commands fully. Also it's awfully slow.
Programming a prefix and suffix for a scanner is specific for each scanner. We have had a lot of scanner and each had different ways to program. You have to consult your scanner manual for that. You may also need to disable the default suffix (chr 13).
You would not want a checkbox as a checkbox requires someone to set it. I personally would want an integration of the scanner without bothering for it. Just using the scanner when I want to is better then enabling a checkbox and scanning.
Ascii 13 is a bad way to detect barcode data. 13 is also the enter key so a user entering data and finalizing data entry with enter would also trigger the barcode action. I suggest you program a prefix and a suffix. We at work always use chr(2) (STX) and chr(3) (ETX) for this.
You can't pass strings as parameters to windows that don't belong to your process as the process can't access variables within your address space. A solution would be allocating memory within the other process memory space and storing the string there.
I want to remotely read the download queue of the file(s) in the listview of eMule (a popular p2p client). I've succesfully read the contents of an open explorer listview and the desktop listview but somehow the the listview of eMule doesn't respond to the LVM_GETITEMTEXT message I send it. Also...
This has the disadvantage that you use three characters to transmit one (eg. chr(0) becomes 000). That will reduce the theoretical technical transferrate from full to 1/3 of the original. I would go for the hex transmit. (0 becomes 00)
You should also subclass the form to prevent flickering of the picture. WM_NCACTIVATE and WM_NCPAINT are I believe the message's to be processed.
Used it once to make a fourth button aside from the three that windows provides. Great fun....
If a secure logon is the main thing to achieve then you also could ask the user for a password and validate it against a stored hash (MD5, SHA256) in program code or located in a database.
I use the InIDE function for several things.
For example:
- Functions like Createmutex for prev instance checking I don't want to be executed in design time. (I know BTW of the App.Previntance function, I just don't want to use it)
- Subclassing I don't always want to use within the IDE. Once...
To much API for no use :)
Use this:
Private Function InIDE() As Boolean
On error Goto ImInIDE
Debug.Print 3/0
InIde = False
Exit Function
ImInIDE:
InIDE = True
End Function
Only in the IDE the Debug.Print expressions are evaluated so as Exe the Debug.Print doesn't exist...
As far as I know the windows key cannot be temporarily be disabled while you run your program and afterward be enabled using only VBA code. I have working code under VB6 that uses a low level keyboard hook to lock the windows key. But a VBA program doesn't support this (as far as I know)...
- The background image I reject instantly. It's unprofessional :)
- Making the wallpaper transparent and showing my picture through is worth a try.
- Making the listview ownerdrawn... mmm, ok, but a little bit tricky to test with the desktop. I guess I'll go for a simple listview in my own...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.