dhouston wrote:I do not understand the term create a new message number for it. I think the message number (i.e. mesg) has to be defined by the sender of the message. I can then hook that message number (once I know it) and capture the data. Or are you saying I need to create a number, pass it in mesg when I call your function, and then hook that message number?
There may not be a need to create a new message number. If you can guarantee that a certain parameter combination can be recognized by your hook code and that combination would not otherwise occur, you're all set.
My suggestion for subclassing and creating a new message number is the typical way of adding functionality to an existing control. Say you have a control that does nearly what you want but you need some extra functionality. You can add functionality for message new message number (one that you know the existing control will not receive otherwise) by writing code to handle that message and pass all other messages through to the underlying control. Often, in processing the new message you'll use the parameters passed with the new message and then send one or more messages to the underlying control to accomplish your desired function. The reason that you want to use an otherwise unused message number is to ensure that you don't interefere with anything that the existing control does now.
You can get a unique message number by using the Windows API RegisterWindowMessage(). That API takes a string and returns a unique message number corresponding to that string. Using the same string again will get you the same message number; a different string will get you a different message number. Consequently, you need to choose a string that is unlikely to have been used by any other callers of that API.
After beating my head against the wall for awhile to knock the rust off some brain cells, I started to recall some of the details including the RegisterWindowsMessage API. It's been a few years since I've done much of this.
I should be able to use WM_USER (0x0400) since I'm not using any other user defined messages. I don't think I need to call RegisterWindowsMessage for this.
Last edited by DH* on 30 June 2006, 17:12 PM, edited 1 time in total.
dhouston wrote:I should be able to use WM_USER (0x0400) since I'm not using any other user defined messages. I don't need think I need to call RegisterWindowsMessage for this.
If WM_USER is not already being used by the control in question then you're all set. Many custom controls base their control-specific messages at WM_USER (e.g. WM_USER + 0, WM_USER + 1, etc.). I've written quite a few custom controls, some of which were superclasses of existing controls (e.g. an enhanced edit control) while others were built from the ground up. The control-specific messages were virtually always based on WM_USER as described above.
Although it is slightly more work, it generally safer to use RegisterWindowMessage() so that you know for certain that your message number won't already be in use.
I have implemented the ability to specify an additional flag to get the progress message to contain a pointer to text as the lParam. This would allow the use of WM_SETTEXT. I'll probably post an updated .zip file by Monday at the latest.
dkinzer wrote:I have implemented the ability to specify an additional flag to get the progress message to contain a pointer to text as the lParam. This would allow the use of WM_SETTEXT. I'll [...] post an updated .zip file[...].
In addition, I have improved the sample application. It now contains a combo box for selecting the serial port and an edit box for entering the file to process along with a browse button for selecting the file. If the -c option is used on the command line, the accompanying port value is used to automatically select the corresponding COM port in the combobox. Otherwise, COM1 is selected by default (unless there is an environment variable ZLOAD_PORT that has a numeric value). If a filename is specified on the command line, it is transferred to the edit box.
The new sample application does not institute the download/update automatically when parameters are supplied on the command line. Instead, it awaits a click on the Send button. However, specifying -i on the command line will cause it to operate in "immedate mode" and the file will be sent to the ZX and then the application will terminate.
It works using VB4-32 and the freeware MsgHook control to handle the message. Being able to display the percentage download completed from within my own app is exactly what I was looking for. It makes it seamless for my users.
The ZIP file includes my VB4-32 code and screenshots showing my download form while updating the VM and application.
After using the download DLL 40-50 times without a glitch, it suddenly stopped working. Using flags = &H4001, it returned immediately with no error. If I try it with &H4003, it returned immediately with a ZC COMM TIMEOUT error.
I was able to download the VM afterwards and reloaded the simple Hello World app but the downloader rejected my app for some reason.
Since it appeared to be related to code changes within my app, I commented out recent changes, recompiled and the downloader handled it with no problems.
If you have a .zxb file that cannot be downloaded and a related one (by minor code changes as you intimated) that can be downloaded, I'd like to get both of them for further examination.
It must have been a compiler burp. When I uncommented the lines in an attempt to isolate the offensive line(s) and recompiled, it was again OK. If it happens again I'll try to send you the ZXB files.