Mark
Are you using the
wxEVT_UPDATE_UI the enable/disable the menu items. I think this is a very
elegant solution.
Nigel
···
On Thu, 16 Jan 2003 09:43:52 -0500 Mark Melvin <Mark.Melvin@dspfactory.com> wrote:
I appreciate all the responses - it sounds like 99% of people would
simply disable the menu items. Well, I'm not really a big fan of this
approach. That was the way I did it initially, and it just seemed like
kind of a hacky solution. One thing that happens is, when a user
navigates a menu during an upload, it prevents the UI from updating.
Thus, they have no idea the upload is finished until they get out of
the menus, then everything BLAM! suddenly appears in the application
window. It just doesn't look very professional. Also, 90% of my menu
items will need to be disabled, because I can only have one process
using the COM port at any one time. It seems like a pain to have to add
each new menu item to a method which disables/enables it all the time.
You mau say - 'Easy enough, just disable all menus at the top level.!'.
Well, I tried that too - even when disabled, the user can still click
them, effectively preventing the UI from updating until they click
elsewhere, deselecting the disabled menu item. It just looks and
behaves wrong.I prefer a busy dialog (like the one provided in wxBusyInfo), or locking
the GUI like I am doing (but with a busy cursor ;o) ). FWIW, I tried
the wxWindowDisabler as suggested and it does exactly the same thing.
As soon as I call wxYield (or wxSafeYield), the cursor reverts back to
'non-busy'. And I need to call wxYield for the UI updates to happen. I
have tried everything I can think of, but it doesn't look like this is
possible - unless someone has any other ideas.One final, related question - if you wanted to update the statusbar of
the application with a message from another thread, what would be the
"safe" way to do it? The only solution I can see without issuing any
"GUI code" from a non-GUI thread would be to subclass to my own custom
event which would call a method to add text to the statusbar, then post
that custom event from the other thread, setting the event data to the
message I wanted to put onto the statusbar.Thanks for all the help,
Mark.Mark Melvin wrote:
> Well, there is really nothing useful you would want to do while
> downloading/uploading. The problem is there are MANY menu items which
> can initiate communications on an already busy link (most of them, in
> fact). My initial code disabled them all, then re-enabled them all
> and it was very hokey in my opinion. Popping up a warning for each
> menu item is not something I would want to do. Neither is queuing the
> events (I tried that, briefly as well). Users will undoubtedly start
> clicking 100 times, wondering why it wasn't downloading.
>
> My current solution works wonderfully, and is the best of all of the
> solutions I have tried in my opinion - I am just curious about how to
> show a busy cursor. Ultimately I will probably throw up a progress
> dialog with a Stop button (and maybe even use a Throbber!), which I
> could make modal and solve all of my problems. Right now, I give them
> feedback in the status bar (which works due to wxSafeYield()) and all
> is good. I just can't get the cursor to stay busy.
>
> Thanks for the feedback.
> Mark.
>
>> In order by my prefrence, you could queue the second download, handle
>> the
>> menu pick by telling the user to wait (pop up an error dialog), or
just
>> disable the download menu selection.
>>
>> Disabling the whole UI seems pretty drastic...
>>
>> /cco
>>
>> On Wed, 15 Jan 2003, Mark Melvin wrote:
>>
>>
>>
>>> Well, the point of locking the GUI is so that the user cannot click
>>> Tools...Download, and spawn a second process.
>>> Also, I have an upload function which also locks the GUI from user
>>> input the same way, but updates the screen with hunks of data as it
>>> is uploading. The whole motivation for the separate thread was
>>> because without it, if it takes too long, the app locks (the good
>>> ole' 'Not Responding' in Windows task manager). I assumed this was
>>> because it could not respond to normal paint events etc.
>>> Anyway, a separate thread is definitely the way to go here, the
>>> question is then - what is the *proper* way to disable user input.
>>> It sounds like I need to look into wxWindowDisabler.
>>>
>>
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
> For additional commands, e-mail:
wxPython-users-help@lists.wxwindows.org
>
>
--
Nigel W. Moriarty
Building 4R0230
Physical Biosciences Division
Lawrence Berkeley National Laboratory
Berkeley, CA 94720-8235
Phone : 510-486-5709
Fax : 510-486-5909
Email : NWMoriarty@LBL.gov
Web : CCI.LBL.gov