1. RE: Thanks
- Posted by Jonas Temple <jtemple at yhti.net> Jun 17, 2003
- 440 views
Pete, Welcome to the community! In Win32Lib V59.1 there's setMousePointer() to change the pointer used so if you're wanting to show that you're busy then you could: setMousePointer(MyWindow, WaitPointer) -- some code here -- Don't forget to set it back! restoreMousePointer(MyWindow) HTH, Jonas > I do have a question, there are times in my program where I am running a > windows command in the background and > while waiting for this to complete I just want to show some kind of > 'Busy'. I am using progress bars (just as timers really) > and 'Please Wait' messages but I would like to show the usual busy > cursor when the mouse is over the programs > window and I haven't been able to figure this out. Can anyone help? > > Regards Pete.
2. RE: Thanks
- Posted by Jonas Temple <jtemple at yhti.net> Jun 17, 2003
- 413 views
Pete, I've noticed the same things but haven't really given it too much thought. Maybe what should happen is in setMousePointer if you pass a window it should set the mouse pointer for ALL child controls of that window? As far as the different pointer not appearing, in my experience it seems that the mouse pointer doesn't get updated unless you stick a few doEvents() in the code following the setMousePointer(). I can only assume that Windows has to get back control to make the mouse change and if you have long running code after setMousePointer() Windows never gets a chance. Derek, any thoughts? Jonas pete_stoner at btconnect.com wrote: > > > Thanks Jonas > That does what I want - almost.. Maybe I'm being stupid (it > happens!!) > I notice that if I set the busy mouse for a window, it only shows the > busy > in 'unused' areas > of the window i.e moving the mouse over any defined fields (Buttons etc) > makes it revert to normal > then back to busy when I'm off a button. > I also found that when I use it within a button click procedure (even as > the > first statement) it doesn't kick into life till after the following code > (which rather defeats the > object!). I even tried putting it in on down event for the button and on > the > open event for > my 'Please Wait'.... Help! > > Regards Pete
3. RE: Thanks
- Posted by michaelstee at yahoo.com Jun 17, 2003
- 413 views
I've noticed this as well. The behavior of setMousePointer() seems to have changed since about version 0.55 or 0.57. The mouse pointer doesn't change when I call setMousePointer(Win,WaitPointer), but after processing files, the pointer changes (to an hourglass) when I call setMousePointer(Win,NULL). Jonas Temple wrote: > > > Pete, > > I've noticed the same things but haven't really given it too much > thought. > > Maybe what should happen is in setMousePointer if you pass a window it > should set the mouse pointer for ALL child controls of that window? > > As far as the different pointer not appearing, in my experience it seems > > that the mouse pointer doesn't get updated unless you stick a few > doEvents() in the code following the setMousePointer(). I can only > assume that Windows has to get back control to make the mouse change and > > if you have long running code after setMousePointer() Windows never gets > > a chance. > > Derek, any thoughts? > > Jonas > pete_stoner at btconnect.com wrote: > > > > > > Thanks Jonas > > That does what I want - almost.. Maybe I'm being stupid (it > > happens!!) > > I notice that if I set the busy mouse for a window, it only shows the > > busy > > in 'unused' areas > > of the window i.e moving the mouse over any defined fields (Buttons etc) > > makes it revert to normal > > then back to busy when I'm off a button. > > I also found that when I use it within a button click procedure (even as > > the > > first statement) it doesn't kick into life till after the following code > > (which rather defeats the > > object!). I even tried putting it in on down event for the button and on > > > > the > > open event for > > my 'Please Wait'.... Help! > > > > Regards Pete >
4. RE: Thanks
- Posted by Martin Stachon <martin.stachon at worldonline.cz> Jun 18, 2003
- 415 views
jbrown105 at speedymail.org wrote: > That makes sense with cooperative multitasking. Preemptive multitasking > doesn't really need this however. > > Also the need to release the cpu is present in all OSes which allow > multitaskingm > not just event driven programs. > > I write this because I don't understand why one must litter the code > with > doEvent() calls. I've never had to do this with GUI programming in > Linux. > (In fact, aside from sleep(), Linux seems to not even HAVE a doEvents() > equivelent, > tho I haven't looked very hard for one.) > > I know that doEvents() comes from Win 3.1, which was a cooperative OS, > but > why do more modern Windoze OSes need it? > > Very curious, > jbrown The problem is that Euphoria is not multi-threaded rather than in OS. While we are doing a longer computation (ie not returning from event handler in win32lib), we cannot call ?GetNextMessage? (forgot the actual function name) and Windows are stacking up events in application queue. But Windows require the application to handle the event. For example, if you move a window, WM_MOVE message is issued, but until your application process the message, the window is not actually moved (the application may say it cannot be moved). The OS could possibly have timeouts for events, and do default processing after timeout, but you would loose a lot of user's actions when high CPU load or application being busy. If we had at least two threads, win32lib would set up separate thread just to handle window events, but the way it is we must call doEvents() occasionaly in longer code to handle event queue. Martin
5. RE: Thanks
- Posted by Jonas Temple <jtemple at yhti.net> Jun 18, 2003
- 425 views
That's why I've asked Rob in the past about the possibility of threads in Eu. I've got some programs that could really benefit from having threads. I'll keep hoping... Jonas Martin Stachon wrote: > > > The problem is that Euphoria is not multi-threaded rather than in OS. > While we are doing a longer computation (ie not returning from event > handler in win32lib), we cannot call ?GetNextMessage? (forgot the actual > > function name) and Windows are stacking up events in application queue. > But Windows require the application to handle the event. For example, if > > you move a window, WM_MOVE message is issued, but until your application > > process the message, the window is not actually moved (the application > may say it cannot be moved). The OS could possibly have timeouts for > events, and do default processing after timeout, but you would loose a > lot of user's actions when high CPU load or application being busy. > > If we had at least two threads, win32lib would set up separate thread > just to handle window events, but the way it is we must call doEvents() > occasionaly in longer code to handle event queue. > > Martin >
6. RE: Thanks
- Posted by mistertrik at hotmail.com Jun 18, 2003
- 419 views
Actually.... after pondering possible implementation of threads, I had an idea... what does the list think of this: I thought hey, wouldn't it be nice to call functions and procs and have it return immediately to the calling process, and have the sub proceed independantly, like a thread? Rationalising... a function couldn't possibly work, cause the calling function depends on the value that is returned.... and a thread never returns, it just ends... Well, what about adding a third subroutine? Call it thread or something. It's given certain parameters, and called like a normal procedure... however the parent continues after that, and the thread subroutine continues in parallel... when it finishes, it doesn't go back to the parent, cause the parent's moved on. It just stops. Okay, possible problems: 1. Race Conditions: Well, we would need to have support for semaphores added, at least. signal and wait could act on normal euphoria integers. Other multi-processing things can be discussed..... 2. Existing code: If a thread calls a library function, there are no guaruntees as to what that code would do if it wasn't written with concurrency in mind... So, we need to safeguard the integrity of the library's data. If there are two threads that both call a function or try and change the data in the same library, then whichever one gets there first does so without problems, and the other is suspended until the first thread finishes. ===================================================== .______<-------------------\__ / _____<--------------------__|=== ||_ <-------------------/ \__| Mr Trick >From: Jonas Temple <jtemple at yhti.net> >Reply-To: EUforum at topica.com >To: EUforum <EUforum at topica.com> >Subject: RE: Thanks >Date: Wed, 18 Jun 2003 13:08:04 +0000 > > >That's why I've asked Rob in the past about the possibility of threads >in Eu. I've got some programs that could really benefit from having >threads. > >I'll keep hoping... > >Jonas >Martin Stachon wrote: > > > > > > The problem is that Euphoria is not multi-threaded rather than in OS. > > While we are doing a longer computation (ie not returning from event > > handler in win32lib), we cannot call ?GetNextMessage? (forgot the actual > > > > function name) and Windows are stacking up events in application queue. > > But Windows require the application to handle the event. For example, if > > > > you move a window, WM_MOVE message is issued, but until your application > > > > process the message, the window is not actually moved (the application > > may say it cannot be moved). The OS could possibly have timeouts for > > events, and do default processing after timeout, but you would loose a > > lot of user's actions when high CPU load or application being busy. > > > > If we had at least two threads, win32lib would set up separate thread > > just to handle window events, but the way it is we must call doEvents() > > occasionaly in longer code to handle event queue. > > > > Martin > > > > > >TOPICA - Start your own email discussion group. FREE! > >