1. RE: Thanks
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
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
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
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
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
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!
>
>
