Hi Dirk
Dirk Traulsen wrote:
> I followed the 'problem with Gauge on windows xp...'
discussion and I'm
> having difficulties to understand the resulting code
from Alex. As my
> problems are not connected to Tims problem, I start a
new one.
>
Cool - it's been a useful thread for me too.
> Please bear in mind that these are questions because I
would like to
> understand the code and are not meant as a critical
comment about the
> code.
>
I made quick minimal changes to the original code to address
the
threading only, and Tim's code was extracted from a real
app, so some
elements may well be redundant.
>>  dialog.status_label.label = "Faking download
# of #: #"
>>
>
> 1. Is there any advantage of writing "#"
instead of "10" here, I
> don't see?
>
No, there isn't. I guess in Tim's code it was a place holder
where in
the real code a variable would go.
>> dialog.update
>> dialog.progress_all.value = (100 * (idx/10.0)).to_i
>> worker = Thread.new do
>> Thread.current[:progress] = 0
>>
>
> 2. Is Thread.current not identical with self inside the
block?
>
No, self remains the same as it was (in this case, the
instance of
XRCTest). It's a new execution thread, but nothing about the
scope
changes. Compare - a File.open do ... end block doesn't
change "self" to
the file within it.
> 3. Why do we have to define the thread-local progress
here? Without
> this line it would also be defined as a thread-local
variable in the
> upto-block, wouldn't be a block variable and would so
survive the block
> cycles, wouldn't it?
>
Because potentially "monitor" could be called
again in the main thread,
and in that, access the local variable before the execution
in the
worker thread reaches the point where the local variable is
set. Then
it'd be passing nil to progress.value= which is an
exception.
Try putting a "sleep 1" in the line immediately
before this, and see
what happens.
>> 1.upto(10) do | count |
>> break if dialog.cancelled
>> Thread.current[:progress] = (100 *
(count/10.0)).to_i
>>
>
> 4. Why is the former dialog.update now
unnecessary?
>
I think Tim was calling update because he wasn't seeing the
dialog
refreshing. But it happened not to be the root of the
problem. All of
the in-built GUI widgets in wxRuby redraw themselves
automatically as
their state changes.
Calling fit or layout upon a sizer is only needed when the
contents of a
container are changed - a widget is removed, or added.
>> sleep(0.1)
>> end
>> if dialog.cancelled
>> Thread.stop
>> end
>>
>
> 5. Why not directely 'Thread.stop if dialog.cancelled' in the upto-
> block? finish exits in this case anyway. What am I
overlooking?
>
That should work too and save a few lines, though I haven't
tested.
>> dialog.progress_all.value = 100
>> dialog.hide
>> md = Wx::MessageDialog.new(dialog,
'Fake download(s) complete!',
>> TITLE, Wx::OK,
Wx: EFAULT_P
OSITION)
>> md.show_modal
>> dialog.hide
>>
>
> 6. Why do we need 'dialog.hide' two times?
>
We don't 
hth
alex
_______________________________________________
wxruby-users mailing list
wxruby-usersrubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/wxruby-users
|
