Leaderboard

hi all This one is nowhere near finished - I'd probably call it a proof of concept for now - "GDIControls.au3" needs to be included, then there's a couple of control types that you should be able to create. _GUICtrlGDI_CreateHFader($hGUI, $iX, $iY, $iWidth, $iHeight [, $Colour [, $iStyle [, $iExStyle ]]]) _GUICtrlGDI_CreateVFader($hGUI, $iX, $iY, $iWidth, $iHeight [, $Colour [, $iStyle [, $iExStyle ]]]) _GUICtrlGDI_CreateKnob($hGUI, $iX, $iY, $iWidth, $iHeight [, $Colour [, $iStyle [, $iExStyle ]]]) _GUICtrlGDI_CreateLRKnob($hGUI, $iX, $iY, $iWidth, $iHeight [, $Colour [, $iStyle [, $iExStyle ]]]) _GUICtrlGDI_CreateVMeter($hWnd, $iX, $iY, $iWidth, $iHeight [, $iStyle [, $iExStyle]]) _GUICtrlGDI_CreateHMeter($hWnd, $iX, $iY, $iWidth, $iHeight [, $iStyle [, $iExStyle]]) _GUICtrlGDI_Create7SegDisplay($hGUI, $iX, $iY, $iWidth, $iHeight [, $Colour [, $iStyle [, $iExStyle ]]]) _GUICtrlGDI_Create14SegDisplay($hGUI, $iX, $iY, $iWidth, $iHeight [, $Colour [, $iStyle [, $iExStyle ]]]) The above functions return a controlID which can be read with GuiCtrlRead() via the usual methods. The controls can also be manipulated with GuiCtrlSetData() Valid values can be from 0 through to 127. That's about the long and short of it! ---------- Theres a bit going on with the mechanics of it here, and I'm sure theres probably a better way of going about things... But for anyone who' s interested this is what's going on: I take the requested dimentions of the control, If there's already bitmaps available for the requested type/dimentions/colour we use those. Otherwise, we dynamically generate a set of 128 bitmaps for the control. The next step is to create a "static" control, which is basically the same as a label. With the right style we can push images to these however. At this stage those optional $iStyle and $iExStyle flags come into play. There are some forced style values to make things work, but hey, if you want to add $WS_BORDER or something I'm not gonna stop ya! Static controls are pretty dumb, but they do know when they're clicked on ($STN_CLICKED). This is enough to let me know that a control needs updating. Next we need to track the mouse. We need to know when and where the mouse in released. I can't really utillise the $GUI_EVENT_* method for this. I'd either have to force OnEvent() mode, or we'd have to ask the user to call some function in the Main GuiGetMsg() Loop. So then I thought of handling $WM_MOUSEMOVE. This works great until you move over a control in the client area! It seems the message gets gobbled up. So now I'm using a low-level mouse hook. With this I can find where we are relative to the control and update it accordingly. The next peice of the puzzle is to let the user know that something has been done. I can easily provide a "getter" function that retrieves the control's values. I'd rather not have a bespoke function for this though. So I thought its better to associate dummy controls, which I use as a delivery mechanism. Lastly we need have a method of updating the control from outsige the GUI. For ease of use we probably want to leverage GuiCtrlSetData(). Setting the dummy control this way puts us in the same predicament as earlier however - we can't really use GuiGetMsg() to monitor it. but we can periodically check the value of the dummy control with an adlib function. If the value of the dummy is not where the GDI control was set with the GUI, we know we need to update it! GDICtrls_1-9.zip

Sendmessage sendinput and keybd_event you can google and are lowest way of simulating keyboard and mouse. You can read faq 31 telling the most information. Mousemove and mouseclick are then the lowest functions to move and click. https://www.autoitscript.com/autoit3/docs/functions/MouseMove.htm The harder it is to identify your controls with spying tools the more creative you have to be to get an x y to move to. There are dozens of discussions on hard to get controls but then you first have to share main window spy information so high-level the technology can be determined where the program is written in.