|
Delayed widget creation
Hi all, Almost have my data import code doing what I want it to, but I seem to be having an issue with delays in the creation of some widgets. What I'm trying to do is have a dialog box that pops up to let the user know that the data import is occurring, and what stage the process is at. The problem is that the while the dialog box gets drawn, none of the widgets get drawn until after all the data import tasks have been done. I have tried to force the creation using recalc, repaint, layout, but nothing seems to be doing the trick.
My code looks like this: if find_customs_file.execute != 0 # get the result from the users selection from a FXFileDialog Box customs_import_dialog = File_Import_Dialog.new(self) # a sublcass of FXDialogBox
customs_import_dialog.create customs_import_dialog.show(PLACEMENT_SCREEN) print "working" customs_data = File.readlines(find_customs_file.filename) print "done"
end So I tried inserting customs_import_dialog.update, or layout, or repaint in there before the call to File.readlines, but nothing helped. The print statements help me track what is going on. Right now the File_Import_Dialog window will get drawn, but with no widgets.. "working" shows up, still no widgets... big pause while the file is imported, then "done" shows up, and finally the full File_Import_Dialog box shows up... which kind of defeats the purpose (that of telling the user something along the lines of "hi there, hold on while I import this file, it's a big one and could take awhile"). I can't tell for certain, but I think the widgets are actually drawn after the "print "done" " statement, and only occurs at the time the "if" statement ends.
Any insights? Thanks, Eric.
_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users
|
|
Re: Delayed widget creation
Long running operations would have to be done in a background thread in order to keep the UI responsive. hth, -- henon On Fri, Sep 18, 2009 at 8:37 PM, Eric Hutton <eric.hutton@...> wrote:
Hi all,
Almost have my data import code doing what I want it to, but I seem to be having an issue with delays in the creation of some widgets.
What I'm trying to do is have a dialog box that pops up to let the user know that the data import is occurring, and what stage the process is at. The problem is that the while the dialog box gets drawn, none of the widgets get drawn until after all the data import tasks have been done. I have tried to force the creation using recalc, repaint, layout, but nothing seems to be doing the trick.
My code looks like this:
if find_customs_file.execute != 0 # get the result from the users selection from a FXFileDialog Box
customs_import_dialog = File_Import_Dialog.new(self) # a sublcass of FXDialogBox
customs_import_dialog.create
customs_import_dialog.show(PLACEMENT_SCREEN)
print "working"
customs_data = File.readlines(find_customs_file.filename)
print "done"
end
So I tried inserting customs_import_dialog.update, or layout, or repaint in there before the call to File.readlines, but nothing helped.
The print statements help me track what is going on. Right now the File_Import_Dialog window will get drawn, but with no widgets.. "working" shows up, still no widgets... big pause while the file is imported, then "done" shows up, and finally the full File_Import_Dialog box shows up... which kind of defeats the purpose (that of telling the user something along the lines of "hi there, hold on while I import this file, it's a big one and could take awhile"). I can't tell for certain, but I think the widgets are actually drawn after the "print "done" " statement, and only occurs at the time the "if" statement ends.
Any insights?
Thanks,
Eric.
_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users
_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users
|
|
Re: Delayed widget creation
On Friday 18 September 2009, Eric Hutton wrote:
> Hi all,
>
> Almost have my data import code doing what I want it to, but I seem to be
> having an issue with delays in the creation of some widgets.
>
> What I'm trying to do is have a dialog box that pops up to let the user know
> that the data import is occurring, and what stage the process is at. The
> problem is that the while the dialog box gets drawn, none of the widgets get
> drawn until after all the data import tasks have been done. I have tried to
> force the creation using recalc, repaint, layout, but nothing seems to be
> doing the trick.
>
> My code looks like this:
> if find_customs_file.execute != 0 # get the result from the users
> selection from a FXFileDialog Box
> customs_import_dialog = File_Import_Dialog.new(self) # a
> sublcass of FXDialogBox
> customs_import_dialog.create
> customs_import_dialog.show(PLACEMENT_SCREEN)
> print "working"
> customs_data = File.readlines(find_customs_file.filename)
> print "done"
> end
>
> So I tried inserting customs_import_dialog.update, or layout, or repaint in
> there before the call to File.readlines, but nothing helped.
>
> The print statements help me track what is going on. Right now the
> File_Import_Dialog window will get drawn, but with no widgets.. "working"
> shows up, still no widgets... big pause while the file is imported, then
> "done" shows up, and finally the full File_Import_Dialog box shows up...
> which kind of defeats the purpose (that of telling the user something along
> the lines of "hi there, hold on while I import this file, it's a big one and
> could take awhile"). I can't tell for certain, but I think the widgets are
> actually drawn after the "print "done" " statement, and only occurs at the
> time the "if" statement ends.
That is correct. Drawing will get done only when the system gets to an
event loop, and processes out-standing redraw events.
To get it to do this BEFORE your callback returns, you must recursively
enter the event loop (presumably, block further user input while in that
subloop and only process non-input type events).
The good news is that this is possible: runModalWhileEvents() is what
you want to call; I suggest calling it during a long-winded file I/O
operation as well, so the screen has a chance to refresh.
The idea is to handle a bunch of events until the event queue is empty, and
then return to the the file import code. You can invoke runModalWhileEvents()
repeatedly, if there is a reason to assume more events have arrived that need
to be handled.
When you first popup a dialog, there is a lot of back-and-forth between X11
server and the application, to resize and redraw items just put on the screen;
after that bunch of events has been handled, things kind of come to a rest and
the window is ready for business.
Note, it works better in FOX 1.7 because this function now as a parameter
to block for a little while, prior to returning with an empty event queue.
The suggestion from Meinrad Recheis is good too, but this is definitely more
complex; but multi-threading may be overkill for this particular situation.
- Jeroen
_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users
|
|
Re: Delayed widget creation
Thanks guys! I'm actually having some luck with .repaint now... of course it started having some effect AFTER I posted my question... but it is only a partial success, back to that in a minute. As to running the file I/O in a different thread and the responsiveness of the UI, while my whole point here is to pop-up a message to tell the user to sit back and relax because there the UI is unresponsive. Basically, there is nothing for the user to interact with until the file is uploaded, so a new thread won't really do anything. Now if could split the file into blocks and multi-thread the upload, that would be a different matter...
I'll have to look into this runModalWhileEvents() though. As I said, I did manage to get the widgets drawn up for the most part with a repaint just before the File.readlines command ( I swear I tried that before!), but as I said it is only partially successful. One of the labels I have is supposed to print out the current time (a call to Time.now), but it is not happening... it starts out just displaying a little tick on the screen, and then the time shows up after the file I/O stuff, and the Time.now value is much later than it should be.... sounds to me, from what you said Jeroen, that ModalWhileEvents() should fix this up... once I read up on how to invoke this properly.
Back to the fun! Once I get a basic version of this messaging dialog complete, I want to try and throw up some sort of spinner graphic to show that the computer is working. I know that there is a progress dialog box, and progress dialog bar, but I found them kind of ugly... also they seem to work best only when you know how much work there is to be done, which isn't the case when opening a file and reading it in for the first time (although I suppose you could get the size of the file, then read one line in and find the size of the line, and then guess at the total number of lines or something...)
Cheers! On Fri, Sep 18, 2009 at 3:14 PM, Jeroen van der Zijp <jeroen@...> wrote:
On Friday 18 September 2009, Eric Hutton wrote:
> Hi all,
>
> Almost have my data import code doing what I want it to, but I seem to be
> having an issue with delays in the creation of some widgets.
>
> What I'm trying to do is have a dialog box that pops up to let the user know
> that the data import is occurring, and what stage the process is at. The
> problem is that the while the dialog box gets drawn, none of the widgets get
> drawn until after all the data import tasks have been done. I have tried to
> force the creation using recalc, repaint, layout, but nothing seems to be
> doing the trick.
>
> My code looks like this:
> if find_customs_file.execute != 0 # get the result from the users
> selection from a FXFileDialog Box
> customs_import_dialog = File_Import_Dialog.new(self) # a
> sublcass of FXDialogBox
> customs_import_dialog.create
> customs_import_dialog.show(PLACEMENT_SCREEN)
> print "working"
> customs_data = File.readlines(find_customs_file.filename)
> print "done"
> end
>
> So I tried inserting customs_import_dialog.update, or layout, or repaint in
> there before the call to File.readlines, but nothing helped.
>
> The print statements help me track what is going on. Right now the
> File_Import_Dialog window will get drawn, but with no widgets.. "working"
> shows up, still no widgets... big pause while the file is imported, then
> "done" shows up, and finally the full File_Import_Dialog box shows up...
> which kind of defeats the purpose (that of telling the user something along
> the lines of "hi there, hold on while I import this file, it's a big one and
> could take awhile"). I can't tell for certain, but I think the widgets are
> actually drawn after the "print "done" " statement, and only occurs at the
> time the "if" statement ends.
event loop, and processes out-standing redraw events.
To get it to do this BEFORE your callback returns, you must recursively
enter the event loop (presumably, block further user input while in that
subloop and only process non-input type events).
The good news is that this is possible: runModalWhileEvents() is what
you want to call; I suggest calling it during a long-winded file I/O
operation as well, so the screen has a chance to refresh.
The idea is to handle a bunch of events until the event queue is empty, and
then return to the the file import code. You can invoke runModalWhileEvents()
repeatedly, if there is a reason to assume more events have arrived that need
to be handled.
When you first popup a dialog, there is a lot of back-and-forth between X11
server and the application, to resize and redraw items just put on the screen;
after that bunch of events has been handled, things kind of come to a rest and
the window is ready for business.
Note, it works better in FOX 1.7 because this function now as a parameter
to block for a little while, prior to returning with an empty event queue.
The suggestion from Meinrad Recheis is good too, but this is definitely more
complex; but multi-threading may be overkill for this particular situation.
- Jeroen
_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users
|
|
Re: Delayed widget creation
OK, very bizarre. So I tried app.runModalWhileEvents instead of [window].repaint but my label displying the value for time.now is still only showing a little squiggle in the upperleft corner until the next screen repaint (after the file IO operation).
The time.now label, when it does show up, is showing the time was calculated at the instance of the call to create the label. On Fri, Sep 18, 2009 at 3:31 PM, Eric Hutton <eric.hutton@...> wrote:
Thanks guys!
I'm actually having some luck with .repaint now... of course it started having some effect AFTER I posted my question... but it is only a partial success, back to that in a minute.
As to running the file I/O in a different thread and the responsiveness of the UI, while my whole point here is to pop-up a message to tell the user to sit back and relax because there the UI is unresponsive. Basically, there is nothing for the user to interact with until the file is uploaded, so a new thread won't really do anything. Now if could split the file into blocks and multi-thread the upload, that would be a different matter...
I'll have to look into this runModalWhileEvents() though. As I said, I did manage to get the widgets drawn up for the most part with a repaint just before the File.readlines command ( I swear I tried that before!), but as I said it is only partially successful. One of the labels I have is supposed to print out the current time (a call to Time.now), but it is not happening... it starts out just displaying a little tick on the screen, and then the time shows up after the file I/O stuff, and the Time.now value is much later than it should be.... sounds to me, from what you said Jeroen, that ModalWhileEvents() should fix this up... once I read up on how to invoke this properly.
Back to the fun! Once I get a basic version of this messaging dialog complete, I want to try and throw up some sort of spinner graphic to show that the computer is working. I know that there is a progress dialog box, and progress dialog bar, but I found them kind of ugly... also they seem to work best only when you know how much work there is to be done, which isn't the case when opening a file and reading it in for the first time (although I suppose you could get the size of the file, then read one line in and find the size of the line, and then guess at the total number of lines or something...)
Cheers!On Fri, Sep 18, 2009 at 3:14 PM, Jeroen van der Zijp <jeroen@...> wrote:
On Friday 18 September 2009, Eric Hutton wrote:
> Hi all,
>
> Almost have my data import code doing what I want it to, but I seem to be
> having an issue with delays in the creation of some widgets.
>
> What I'm trying to do is have a dialog box that pops up to let the user know
> that the data import is occurring, and what stage the process is at. The
> problem is that the while the dialog box gets drawn, none of the widgets get
> drawn until after all the data import tasks have been done. I have tried to
> force the creation using recalc, repaint, layout, but nothing seems to be
> doing the trick.
>
> My code looks like this:
> if find_customs_file.execute != 0 # get the result from the users
> selection from a FXFileDialog Box
> customs_import_dialog = File_Import_Dialog.new(self) # a
> sublcass of FXDialogBox
> customs_import_dialog.create
> customs_import_dialog.show(PLACEMENT_SCREEN)
> print "working"
> customs_data = File.readlines(find_customs_file.filename)
> print "done"
> end
>
> So I tried inserting customs_import_dialog.update, or layout, or repaint in
> there before the call to File.readlines, but nothing helped.
>
> The print statements help me track what is going on. Right now the
> File_Import_Dialog window will get drawn, but with no widgets.. "working"
> shows up, still no widgets... big pause while the file is imported, then
> "done" shows up, and finally the full File_Import_Dialog box shows up...
> which kind of defeats the purpose (that of telling the user something along
> the lines of "hi there, hold on while I import this file, it's a big one and
> could take awhile"). I can't tell for certain, but I think the widgets are
> actually drawn after the "print "done" " statement, and only occurs at the
> time the "if" statement ends.
event loop, and processes out-standing redraw events.
To get it to do this BEFORE your callback returns, you must recursively
enter the event loop (presumably, block further user input while in that
subloop and only process non-input type events).
The good news is that this is possible: runModalWhileEvents() is what
you want to call; I suggest calling it during a long-winded file I/O
operation as well, so the screen has a chance to refresh.
The idea is to handle a bunch of events until the event queue is empty, and
then return to the the file import code. You can invoke runModalWhileEvents()
repeatedly, if there is a reason to assume more events have arrived that need
to be handled.
When you first popup a dialog, there is a lot of back-and-forth between X11
server and the application, to resize and redraw items just put on the screen;
after that bunch of events has been handled, things kind of come to a rest and
the window is ready for business.
Note, it works better in FOX 1.7 because this function now as a parameter
to block for a little while, prior to returning with an empty event queue.
The suggestion from Meinrad Recheis is good too, but this is definitely more
complex; but multi-threading may be overkill for this particular situation.
- Jeroen
_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users
|
|
Re: Delayed widget creation
OK, I think I have it now.. a call to .layout followed by a call to .repaint seems to be doing the trick. On Fri, Sep 18, 2009 at 4:41 PM, Eric Hutton <eric.hutton@...> wrote:
OK, very bizarre. So I tried app.runModalWhileEvents instead of [window].repaint but my label displying the value for time.now is still only showing a little squiggle in the upperleft corner until the next screen repaint (after the file IO operation).
The time.now label, when it does show up, is showing the time was calculated at the instance of the call to create the label.On Fri, Sep 18, 2009 at 3:31 PM, Eric Hutton <eric.hutton@...> wrote:
Thanks guys!
I'm actually having some luck with .repaint now... of course it started having some effect AFTER I posted my question... but it is only a partial success, back to that in a minute.
As to running the file I/O in a different thread and the responsiveness of the UI, while my whole point here is to pop-up a message to tell the user to sit back and relax because there the UI is unresponsive. Basically, there is nothing for the user to interact with until the file is uploaded, so a new thread won't really do anything. Now if could split the file into blocks and multi-thread the upload, that would be a different matter...
I'll have to look into this runModalWhileEvents() though. As I said, I did manage to get the widgets drawn up for the most part with a repaint just before the File.readlines command ( I swear I tried that before!), but as I said it is only partially successful. One of the labels I have is supposed to print out the current time (a call to Time.now), but it is not happening... it starts out just displaying a little tick on the screen, and then the time shows up after the file I/O stuff, and the Time.now value is much later than it should be.... sounds to me, from what you said Jeroen, that ModalWhileEvents() should fix this up... once I read up on how to invoke this properly.
Back to the fun! Once I get a basic version of this messaging dialog complete, I want to try and throw up some sort of spinner graphic to show that the computer is working. I know that there is a progress dialog box, and progress dialog bar, but I found them kind of ugly... also they seem to work best only when you know how much work there is to be done, which isn't the case when opening a file and reading it in for the first time (although I suppose you could get the size of the file, then read one line in and find the size of the line, and then guess at the total number of lines or something...)
Cheers!On Fri, Sep 18, 2009 at 3:14 PM, Jeroen van der Zijp <jeroen@...> wrote:
On Friday 18 September 2009, Eric Hutton wrote:
> Hi all,
>
> Almost have my data import code doing what I want it to, but I seem to be
> having an issue with delays in the creation of some widgets.
>
> What I'm trying to do is have a dialog box that pops up to let the user know
> that the data import is occurring, and what stage the process is at. The
> problem is that the while the dialog box gets drawn, none of the widgets get
> drawn until after all the data import tasks have been done. I have tried to
> force the creation using recalc, repaint, layout, but nothing seems to be
> doing the trick.
>
> My code looks like this:
> if find_customs_file.execute != 0 # get the result from the users
> selection from a FXFileDialog Box
> customs_import_dialog = File_Import_Dialog.new(self) # a
> sublcass of FXDialogBox
> customs_import_dialog.create
> customs_import_dialog.show(PLACEMENT_SCREEN)
> print "working"
> customs_data = File.readlines(find_customs_file.filename)
> print "done"
> end
>
> So I tried inserting customs_import_dialog.update, or layout, or repaint in
> there before the call to File.readlines, but nothing helped.
>
> The print statements help me track what is going on. Right now the
> File_Import_Dialog window will get drawn, but with no widgets.. "working"
> shows up, still no widgets... big pause while the file is imported, then
> "done" shows up, and finally the full File_Import_Dialog box shows up...
> which kind of defeats the purpose (that of telling the user something along
> the lines of "hi there, hold on while I import this file, it's a big one and
> could take awhile"). I can't tell for certain, but I think the widgets are
> actually drawn after the "print "done" " statement, and only occurs at the
> time the "if" statement ends.
event loop, and processes out-standing redraw events.
To get it to do this BEFORE your callback returns, you must recursively
enter the event loop (presumably, block further user input while in that
subloop and only process non-input type events).
The good news is that this is possible: runModalWhileEvents() is what
you want to call; I suggest calling it during a long-winded file I/O
operation as well, so the screen has a chance to refresh.
The idea is to handle a bunch of events until the event queue is empty, and
then return to the the file import code. You can invoke runModalWhileEvents()
repeatedly, if there is a reason to assume more events have arrived that need
to be handled.
When you first popup a dialog, there is a lot of back-and-forth between X11
server and the application, to resize and redraw items just put on the screen;
after that bunch of events has been handled, things kind of come to a rest and
the window is ready for business.
Note, it works better in FOX 1.7 because this function now as a parameter
to block for a little while, prior to returning with an empty event queue.
The suggestion from Meinrad Recheis is good too, but this is definitely more
complex; but multi-threading may be overkill for this particular situation.
- Jeroen
_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users
|
|
Re: Delayed widget creation
On Friday 18 September 2009, Eric Hutton wrote:
> OK, very bizarre. So I tried app.runModalWhileEvents instead of
> [window].repaint but my label displying the value for time.now is still only
> showing a little squiggle in the upperleft corner until the next screen
> repaint (after the file IO operation).
>
> The time.now label, when it does show up, is showing the time was calculated
> at the instance of the call to create the label.
The flaw in the original runModalWhileEvents() was to return when the event
queue was empty. The newer version in FOX 1.7 has a timeout parameter, which
allows it to wait a little while before giving on an empty event queue.
This is better since event queue being empty on the client side doesn't mean
the event queue on the server-side is empty yet...
- Jeroen
_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users
|
|
Re: Delayed widget creation
Thanks Jeroen, that makes sense. Got things working for now though... but I'll have to follow up on that when we have FxRuby 1.7 to play with. On Fri, Sep 18, 2009 at 5:24 PM, Jeroen van der Zijp <jeroen@...> wrote:
On Friday 18 September 2009, Eric Hutton wrote:
> OK, very bizarre. So I tried app.runModalWhileEvents instead of
> [window].repaint but my label displying the value for time.now is still only
> showing a little squiggle in the upperleft corner until the next screen
> repaint (after the file IO operation).
>
> The time.now label, when it does show up, is showing the time was calculated
> at the instance of the call to create the label.
The flaw in the original runModalWhileEvents() was to return when the event
queue was empty. The newer version in FOX 1.7 has a timeout parameter, which
allows it to wait a little while before giving on an empty event queue.
This is better since event queue being empty on the client side doesn't mean
the event queue on the server-side is empty yet...
_______________________________________________
fxruby-users mailing list
fxruby-users@...
http://rubyforge.org/mailman/listinfo/fxruby-users
|
