Jump to content

Best method to receive messages posted from another process?


 Share

Recommended Posts

Dear AutoIt gurus

I am using AutoIt to develop quick and reconfigurable GUI control of occasional bits of hardware e.g a multiported valve. This works really well for me, but I now wish to make an extension. Typically only one process can have control of the hardware so if another program (written by me but not in AutoIt) needs to use the valve I currently have to shut the AutoIt script down. What I would prefer to do is add to the script so that it provides control of the valve to other programs whilst continuing to display its state on the screen.

My current thinking is to try and arrange that the Autoit script will respond to windows messages that I can send from the other process. I have found GUIRegisterMsg and note that it only claims to cover "known Windows messages". I guess this means I can't go via the Windows API RegisterWindowMessage() route as I'd have no way to receive such messages in the AutoIt script. I am thinking I could use WM_USER, as its in the list in the AutoIt help file. Do I also have the option of using messages in the range WM_USER to 0x7fff ?

Does anyone else have experience of making an AutoIt script act in a server capacity like this? Am I on the right track, or have I overlooked a better strategy for interprocess communication?

TIA for any advice

Steve

BTW I am really impressed with AutoIt - many thanks for making it available to the world and also to the guys that have provided all the add-ons, especially Koda. It's done a brilliant job of making the compromise between power and size. It seems to have built in, simple to use, functions for all the normal things I want to do, plus hooks that allow just about anything else if I really want it (and am prepared to consult the Windows API documentation). At the same time being free, small and well documented means I can casually stick it on target system without worrying about how long its going to take to set up and I can leave it on the target system when it ships. We build a lot of one-off scientific instruments; software is not our main business, but inevitably is required. Because the hardware is always non-standard its really helpful to do development on the target system, sometime even on a customers site.

(Sorry if this is the wrong place to say this )

Link to comment
Share on other sites

Dear AutoIt gurus

I am using AutoIt to develop quick and reconfigurable GUI control of occasional bits of hardware e.g a multiported valve. This works really well for me, but I now wish to make an extension. Typically only one process can have control of the hardware so if another program (written by me but not in AutoIt) needs to use the valve I currently have to shut the AutoIt script down. What I would prefer to do is add to the script so that it provides control of the valve to other programs whilst continuing to display its state on the screen.

My current thinking is to try and arrange that the Autoit script will respond to windows messages that I can send from the other process. I have found GUIRegisterMsg and note that it only claims to cover "known Windows messages". I guess this means I can't go via the Windows API RegisterWindowMessage() route as I'd have no way to receive such messages in the AutoIt script. I am thinking I could use WM_USER, as its in the list in the AutoIt help file. Do I also have the option of using messages in the range WM_USER to 0x7fff ?

Does anyone else have experience of making an AutoIt script act in a server capacity like this? Am I on the right track, or have I overlooked a better strategy for interprocess communication?

TIA for any advice

Steve

BTW I am really impressed with AutoIt - many thanks for making it available to the world and also to the guys that have provided all the add-ons, especially Koda. It's done a brilliant job of making the compromise between power and size. It seems to have built in, simple to use, functions for all the normal things I want to do, plus hooks that allow just about anything else if I really want it (and am prepared to consult the Windows API documentation). At the same time being free, small and well documented means I can casually stick it on target system without worrying about how long its going to take to set up and I can leave it on the target system when it ships. We build a lot of one-off scientific instruments; software is not our main business, but inevitably is required. Because the hardware is always non-standard its really helpful to do development on the target system, sometime even on a customers site.

(Sorry if this is the wrong place to say this )

Welcome to the AutoIt forums StevJM :)

Handling messages in AutoIt is quite easy. The reference you quote "known Windows messages" is a bit misleading I think because I think it really only means messages that you want to deal with. You can decide to use any number you want that isn't already used. If you keep to to well above $WM_USER you should have no problems. I use values like $WM_USER + 2000.

You could easily arrange it so that the AutoIt script has sole control of the valve and takes instructions from the other programs or tells them to wait, or the AutoIt script could receive requests to control a valve and grant that request if another app didn't already have control.

GUIRegisterMsg($WM_USER + 2000, "GiveMeControl")
Global $Controller = 0;Ref of app in control
.
.
.
;Assuming app sends message requesting control with wparam set to it's unique ID
Func GiveMeControl($hWndGUI, $MsgID, $WParam, $LParam)
    If $MsgID = $WM_USER + 2000 Then
        If $Controller = 0 Then
            $Controller = $WParam
            Return True
        Else
            Return False
        EndIf
    EndIf
EndFunc  ;==>GiveMeControl
Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.
Link to comment
Share on other sites

Martin

Thanks for the rapid and clear answer. Thinking ahead and just to make sure I've understood: if I can really use any message then I do have the option of making use of the Windows API RegisterWindowsMessage() using message numbers in the range 0xC000 through 0xFFFF. Is that correct?

Link to comment
Share on other sites

You are correct, SteveJM. If you search the forums for the RegisterWindowsMessage function, you will find an example of it to use. If not, I planned on using it myself at some point, I'll help you figure it out.

CoProc is a really good example of using windows messages for communicating between processes.
Link to comment
Share on other sites

Thanks for the help and advice guys. The job is now done. Providing the simple valve service took remarkably few additional lines of code. The references you provided also provided some thought provoking tips that I'll probably make use of in the future. The whole exercise has confirmed my intention to make more use of AutoIt.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...