Just finishing up my 1st small utility and noticed that I get a warning in the IDE that says:
"gb.qt5: warning: calling the event loop during a keyboard event handler is ignored"

I get this if I use Ctrl+c or Ctrl+s, which I use as a shortcut in the utility to call a Copy or Save event of an image. Everything appears to work fine but it left me wondering if I shouldn't be using those particular keys or maybe Gambas gives this warning because Gambas itself uses these keys within the IDE. The Ctrl+u that I use doesn't give any warning.

I'm now on Gambas 3.16.3 and Ubuntu 20.04.3. Thanks for any insight.

The error is a QT error, not a Gambas error. I suspect that you have a Form_MouseDown(), or similar, routine that catches all the keyboard activity. With Ctrl-S and Ctrl-C these will be caught by the system as well, so there may be a conflict there. You can ignore the error if all else is well. For more help, please post your program, so we can test it out for you.

 Okay, but don’t laugh too much at my code as I’m still trying to understand a lot of this. Everything seems to work but if I could understand the warning better it would be beneficial.

This utility was made for a specific purpose. I copy a keyword and paste it into a “maps” search-box, on the web. I then save an image of maps results (at a specific size) to a specific folder with the file name consisting of the keyword, date and the number of the client position in the listing(added manually).

I’m trying to switch from Windows to Ubuntu and I need this and one other utility before I can totally leave Windows behind. I’m retired and do a little SEO side-work and this changes a 1 hour job into about 7 minutes for me.

Thank you for taking the time to look at this.

Well, I can't stop the message appearing. Maybe someone else will have an idea about this.

The way you have gone about your screen capture is very novel. I have written a screen capture program, ScreenShot that is on the Gambas Farm if you are interested. Your code looks pretty good to me. I had a good look and have come up with a few ideas, code attached.

The first point is the 'dark art' of the Gambas expanding forms. It takes a bit of grasping. I have removed a lot of the code in the Form_Resize() routine by changing various Properties on the Form and also changed some panels into HBoxes and VBoxes and deleted the ScrollView. There is no quick way to explain all this, again I have put up a program on the Gambas Farm called ExpandingForms that will hopefully help. The code changes I have made are higlighted.

In the Project Properties, if you click on the 'image' you can select a picture that will appear on the desktop when you create an executable with a desktop shortcut.

I hope some of this helps.

<IMG src="https://www.cogier.com/gambas/ScreenCap1.png"> </IMG><IMG src="https://www.cogier.com/gambas/ScreenCap2.png"> </IMG>

 Thanks so much for investing your time on this.
I have downloaded your attachment and will study the modifications. I wanted to use the HBoxes and VBoxes but I don't really understand them well at this point so I fell back on a more comfortable similarity from VB.net. I will definitely look at ExpandingForms in the Gambas Farm as I struggled with this too.

 I believe your error is because you use the "Wait" command in the Capture function.

Wait() in Gambas triggers a function like VB's DoEvents() to check the event loop for pending events, qt does not like it inside a keyboard event handler.

Because the Capture() command is run from the Form_KeyPress() event you are "in the keyboard event handler"  the event loop is then triggered using the Wait command.

Try the Sleep command instead of Wait.


Or run Capture() separate from the event handler using a timer.

attached your project with my RunFree.class added to it and the keyboard event commands now like this…

RunFree(Me, "Capture", [False])


I tested this method with your app and it works,, running that way the keyboard event handler is freed.

 Thanks Bruce for investing your time also. That's an excellent explanation for me. I would've never figured that out.
I've downloaded your attachment and I'll see if I can understand your RunFree.class, it sounds far better than running in a timer. This is very, very helpful.

Diverod said

Thanks Bruce for investing your time also. That's an excellent explanation for me. I would've never figured that out.
I've downloaded your attachment and I'll see if I can understand your RunFree.class, it sounds far better than running in a timer. This is very, very helpful.

you are welcome, the RunFree class does run the function through a timer, by doing so it runs as a separate process to the function calling it,
Using the RunFree() command in the keyboard event handler just sets up the command and starts the timer then continues whilst the timer event actually calls your function.

It's a simple class, i created it in response to having issues that i was told "you shouldn't do that inside an event handler" so I came up with a work around
,It's just this..


To be fair though for the purpose of your app it would be easier to use the Sleep command.  or even better handle the reason you are using Wait properly. Ie, try to find a way to detect what you are waiting for so it will not need adjusting for slower cpu's it will self adjust

All the best

BruceSteers said

Diverod said

Thanks Bruce for investing your time also. That's an excellent explanation for me. I would've never figured that out.
I've downloaded your attachment and I'll see if I can understand your RunFree.class, it sounds far better than running in a timer. This is very, very helpful.

you are welcome, the RunFree class does run the function through a timer, by doing so it runs as a separate process to the function calling it,
Using the RunFree() command in the keyboard event handler just sets up the command and starts the timer then continues whilst the timer event actually calls your function.

It's a simple class, i created it in response to having issues that i was told "you shouldn't do that inside an event handler" so I came up with a work around
,It's just this..

Code (gambas)

1. ' Gambas class file
2.  
3. ' RunFree.class written by Bruce Steers (with some help from Tobias Boege)
4.  
5. ' Syntax..
6. ' RunFree(Parent As Object, Method As String, ArgArray As Variant[])
7.  
8. ' Parent is the class containing the Method (Function/Sub)
9. ' Method is the Function/Sub name
10. ' ArgArray is Variant Array[]
11. ' Eg.
12. ' RunFree(Me, "LengthyMethod",["Some Text", 22, True])
13.  
14.  
15. Export
16.  
17. Static Private $Timer As Timer
18.  
19. Static Private $Parent As Object
20. Static Private $Method As String
21. Static Private $ArgArray As Variant[]
22.  
23. Static Public Sub _init()
24.  
25.   $Timer = New Timer As "Timer"
26.   $Timer.Delay = 0
27.  
28. End
29.  
30.  
31. Static Public Sub _call(Parent As Object, Method As String, Optional ArgArray As Variant[])
32.  
33.   $Parent = Parent
34.   $Method = Method
35.   $ArgArray = ArgArray
36.   $Timer.Start
37.  
38. End
39.  
40. Static Public Sub Timer_Timer()
41.  
42. $Timer.Stop
43. Object.Call($Parent, $Method, $ArgArray)
44.  
45. End
46.  

To be fair though for the purpose of your app it would be easier to use the Sleep command.  or even better handle the reason you are using Wait properly. Ie, try to find a way to detect what you are waiting for so it will not need adjusting for slower cpu's it will self adjust

All the best

Ah, maybe the light bulb is getting brighter! I used Wait because I was getting an artifact from the main form in the image when I was running Ubuntu in Virtualbox. I'm no longer using Virtualbox but it's still set up on my dual-boot laptop so I should be able to go back and test it. Thanks Bruce.

Thanks to all the help here I have learned a great deal and still have a great amount to learn. I have a good memory, it just that it’s short.

Also, before I forget, I wanted to let cogier know that his Screenshot comes preinstalled as a utility in Ubuntu 20.04.3LTS.

Bruce, I haven’t gotten back to my Virtualbox machine to do more testing on the Wait command yet, but I will. Your RunFree.Class is really slick.

The last few days I’ve been chasing a problem with the Ctrl+Up / Down key code and the form displaced by -37 pixels in the Y direction after returning by the Capture() sub with Gambas 3.16.3. Strangely enough, I have a note saying the form jumped in the opposite direction with Gambas 3.14.3.

If I don’t use any Ctrl+Up / Down key the form returns to its proper position. Once you do use a key code the effect remains even if the keys are not used again to position the form.

If I use  Ctrl+Up one time, moving the form up 1 pixel, it jumps up 37 pixels when it returns to the screen. If I then press Ctrl+Down key one time, the form jumps down 37 pixels(original position) + 1.

After days of trying many different things I was able to reduce and resolve  the problem with 2 simple lines of code:
Me.Y += 1
Me.Y -= 1
It’s like the form knows where it’s supposed to be but no one has told it to go there if a key code is used. I truly do not understand what I’m missing on this one.

I’ve attached the updated project if you’d like to look at it. If you want to see the effect just comment out lines 286 & 287.

If you set the main forms Persistent property to True then i think it fixes it as the windows config is not destroyed when closing it.

I edited the prog a little to make it also use the "Stop Event" command if arrow keys are pressed with Ctrl otherwise the arrow keys were also changing button focus.  using "Stop Event" stops the default key press things happening if you are doing other things


and condensed it to run another function..


Ignore the fact i used Me.Window.Top and not Me.Top I was experimenting to see if it made a difference.

BruceSteers said

If you set the main forms Persistent property to True then i think it fixes it as the windows config is not destroyed when closing it.

Eek sorry no it does not

gambas does have issues with form co-ords replacement.  My desktop app will not work correctly either.  if i change window border property it then gives wrong coords and when reloading the window is incorrectly positioned  

 Just thought I’d post the final version of this utility after correcting a minor issue with displayed height. I really appreciate the help from Cogier with cleaning up the layout of the main form and general code improvement and BruceSteer for proper key code handling and his RunFree Class.

I still haven’t found a good alternative for the Wait command but eventually maybe something will come to me when I’m not thinking about it so hard. I learned a lot on this one, especially that I’ve got a lot more to learn.

Thanks to all, RodG.

Diverod said

Just thought I’d post the final version of this utility after correcting a minor issue with displayed height. I really appreciate the help from Cogier with cleaning up the layout of the main form and general code improvement and BruceSteer for proper key code handling and his RunFree Class.

I still haven’t found a good alternative for the Wait command but eventually maybe something will come to me when I’m not thinking about it so hard. I learned a lot on this one, especially that I’ve got a lot more to learn.

Thanks to all, RodG.

Cool app.

I have an idea about the wait issue.
Do not even hide the main form,
just capture the area inside the picturebox view.
hide the colour panel if needed and then grab the area of the PictureBox that's showing the screen beneath (as this is the area it looks like you'll get) not the entire form size area. then the main form can remain open, no more problem

Just a thought