-
Jul 16th, 2019, 07:24 PM
#1
Thread Starter
Fanatic Member
why the normal form from VB6 is buggy?
Do you know, if in any form, you click the X button for closing the form at tittle bar, ALL the VB internal execution is stopped, (I mean timers, events like winsocks receive, etc.)
So, just place the mouse on the X, press and hold the left CLICK , while you are holding it , nothing in the VB code will run, it just STOPS everything, when you releases the click , everything continues as usual.
it can be any form in the exe, don't matter if was launch with form.show 0 , etc... (i didn't tested with child forms).
anyway I am just curious.
PD: It stops timers at others forms aswell.... for my kiosk software that is fatal, so I elimitanted all the normal VB windows frames and titlebars. And forced to include that as part of the skins (all borderless windows)
Last edited by flyguille; Jul 16th, 2019 at 07:28 PM.
-
Jul 16th, 2019, 07:30 PM
#2
Thread Starter
Fanatic Member
Re: why the normal form from VB6 is buggy?
yup, just tested with the virtual mouse aswell, (remote control functionality). both, real and virtual mouse....
PD2: It also happens if doing that in the MINIMIZE button!. WTH!,
Last edited by flyguille; Jul 16th, 2019 at 07:35 PM.
-
Jul 16th, 2019, 07:33 PM
#3
Re: why the normal form from VB6 is buggy?
The behavior you describe is not unique to VB6 programs...
-
Jul 16th, 2019, 07:37 PM
#4
Thread Starter
Fanatic Member
Re: why the normal form from VB6 is buggy?
Originally Posted by OptionBase1
The behavior you describe is not unique to VB6 programs...
please, teachme!.
-
Jul 16th, 2019, 07:40 PM
#5
Re: why the normal form from VB6 is buggy?
Teach you what?
Open minesweeper. Click a box to reveal the first square, which starts the game timer. Click and hold on the x. Does the game timer keep going or does the game timer stay put on the current time?
Do this with any program that is in the middle of doing something and it will almost certainly "freeze".
Not a VB6 issue at all.
-
Jul 16th, 2019, 07:43 PM
#6
Thread Starter
Fanatic Member
Re: why the normal form from VB6 is buggy?
Originally Posted by OptionBase1
Teach you what?
Open minesweeper. Click a box to reveal the first square, which starts the game timer. Click and hold on the x. Does the game timer keep going or does the game timer stay put on the current time?
Do this with any program that is in the middle of doing something and it will almost certainly "freeze".
Not a VB6 issue at all.
wOOOW mouse DOMINATOR!!!!
include in the minimize button, and assume maximize too.
so doing the click, all the times gets ruined. Forget to do critical real time stuff.
a windows only thing?
Last edited by flyguille; Jul 16th, 2019 at 07:48 PM.
-
Jul 16th, 2019, 07:51 PM
#7
Re: why the normal form from VB6 is buggy?
It seems like there was a thread related to this issue at some point here in the last year or so. Not sure what the outcome was, or if there is a specific workaround for VB6 other than to remove the built-in titlebar/toolbox and create your own, which it sounds like you are already doing. I would recommend going with that approach moving forward if it is going to be an issue with your programs.
-
Jul 16th, 2019, 08:34 PM
#8
Re: why the normal form from VB6 is buggy?
Since this is a VB6 forum, I'm a bit reluctant to mention this, but I've had cases where being able to respond to and process periodic interfaces was critical and I discovered that even just clicking and holding on the title bar would hang up the timer for around 400ms, which caused failures to be reported by the interfacing device.
I wasn't actually using VB6 for this, because it was a system provided to me with different language compilers available (e.g. FORTRAN, Ada, C++,...) but VB6 wasn't one of them. But it did have VS2005 available, so I started experimenting with my first exposure to the VB.Net environment with this code.
When I discovered the problem with various mouse actions delaying the timer events, I quickly looked into starting to use background threads to do critical work. This fixed the issues I had.
There was also a way to create an object that could update a graphical display from a background thread, and I did some experimentation with that long ago.
I just looked up one of those experiments and ran the executable to see what would happen if I clicked and held the various buttons on the titlebar.
Click and holding on the buttons or the titlebar had no effect on the background thread, and the graphical display continued to update smoothly showing a scrolling map with various vehicles on it.
However, there were a couple of GUI elements that were also showing information updated by the background thread, i.e. a FPS readout and a counter of some value. Since those values were updated by the background thread, but the readouts were updated by a Timer component (i.e. a timer control in VB6 parlance), those events did stop, and the readouts quit updating.
But as soon as the mouse was moved off of the button (didn't want to have the button action taken) and released, those updates continued, and in the case of the counter, it jumped to its current value as the counter was still being incremented by the background thread while the GUI was "hung".
Now, I know "The Trick" and Olaf (and perhaps others) have threads about doing threading with VB6, so it may be possible to use a secondary thread with VB6 to keep on doing your "critical real time stuff" even if the GUI is hung by mouse interaction.
Of course, Windows is not a real time OS, so the meaning of critical real time in Windows does have to be taken with a grain of salt, as they say.
-
Jul 16th, 2019, 08:47 PM
#9
Fanatic Member
Re: why the normal form from VB6 is buggy?
Are you using VB6 without service packs? Prior to SP3, Timer events don't fire when you show a modal form or MsgBox in the EXE. In the IDE, they don't fire at all in these situations regardless of service pack.
What you are seeing is called a modal loop. When Windows receives some messages, such as WM_ENTERSIZEMOVE, it does its own message processing. This is usually done inside DefWindowProc. Try searching the web for "Modal loop WM_ENTERSIZEMOVE".
I think it also happens when you call TrackPopupMenu, which is the function that shows a context menu when you right click something, but it might depend on the control and maybe the OS, I am not sure.
-
Jul 17th, 2019, 10:06 AM
#10
Re: why the normal form from VB6 is buggy?
Yes, this issue has been discussed before.
Basically, we have to remember that a VB6 program (even if in the IDE) is single-threaded. Therefore, if anything grabs the thread and doesn't have an equivalent of DoEvents in it, nothing else is going to execute until whatever grabbed the thread has completed. (And this is inclusive of timers and any other attempt to raise events.)
A typical example is a long loop. Or, a long call to the Sleep API will do the same thing. Nothing will execute until the loop finishes or Sleep returns.
And, with the non-client area of forms (not specific to VB6), they tend to grab the thread when dragging or doing anything until the user has finished with that non-client area. That's also true of re-sizing a form.
That's about all there is to it.
And, the only work around is to build our own titlebars and resize borders, either including a DoEvents in the code that does the work, or don't keep the thread while the mouse is down.
By the way, this isn't a bug ... it's the way it's designed to work.
Last edited by Elroy; Jul 18th, 2019 at 08:44 AM.
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Jul 17th, 2019, 07:46 PM
#11
Re: why the normal form from VB6 is buggy?
The moral of the story is that you should not do long-running or time-critical work on the UI thread. Doing otherwise may be more difficult in VB6 than in some other languages, simply by virtue of the fact that VB6 is fairly old and there has been a significant emphasis on multi-threading and parallelism more recently, as multi-core processors have become the norm. The use of async/await in recent versions of VB.NET and C# has made such things easier.
-
Jul 17th, 2019, 07:52 PM
#12
Re: why the normal form from VB6 is buggy?
There is always the simple approach of using an ActiveX for background worker threads too. That is usually the simplest place to start, but like any COM server programming the casual user is often defeated by the issues around binary compatibility.
You can also use a non-interactive process as a background worker.
You don't have to make a complicated mess of things. The CodeBank is full of examples of the alternatives.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|