Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

RB thread "paused" whenever a GUI action such as window dragging or resize occurs (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: Fit to Window or Print preview
Next thread: Mac multiple select


Re: XML File Search   -   Dave Shirk
  RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Daniel Stenning
   Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   joe strout.net
    Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Frank Condello
     Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Daniel Stenning
    Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Daniel Stenning
   Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Frank Condello
    Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Daniel Stenning
   Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Frank Condello
    Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs - sign on to FR here...   -   Daniel Stenning
   Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Christian Schmitz
    Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Daniel Stenning
   Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   joe strout.net
    Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Chris Little
     Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Daniel Stenning
    Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Daniel Stenning
   Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Stefan
    Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Chris Little
   Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Frank Condello
    Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Daniel Stenning
   Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Frank Condello
   Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Frank Condello
    Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs   -   Daniel Stenning

RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 03:50 (Thu, 02 Aug 2007 03:50:08 +0100)
From: Daniel Stenning
I am finding a weird thing when dealing with RB threads.

I have a thread which simply loops round as follows:

while true
Process()
wend

It seems that whenever I do a drag on a window, or some mouse action that
this thread gets frozen out. The same seems to apply if I replace a thread
with a loop as above with a timer. Somehow, doing a GUI operation seems to
"pause" the thread. This is not what I would expect. The RB thread should
be oblivious of any mouse action in the main RB app thread.

I know RB threads are sort of co-operative internally as opposed to true
pre-emptive threads, but even so, I wouldn't expect GUI actions to lock out
other RB threads - particularly since I gave the thread a high priority.

Anyone else seeing this ?. This is on an Intel MacBook Pro, and RB R3.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 03:58 (Wed, 1 Aug 2007 20:58:27 -0600)
From: joe strout.net
On Aug 02, 2007, at 02:50 UTC, Daniel Stenning wrote:

> It seems that whenever I do a drag on a window, or some mouse action
> that this thread gets frozen out. The same seems to apply if I
> replace a thread with a loop as above with a timer. Somehow, doing a
> GUI operation seems to "pause" the thread.

Right. That's how it works.

> This is not what I would expect. The RB thread should be oblivious of
> any mouse action in the main RB app thread.

Your expectations require adjustment.

Cheers,
- Joe

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 04:41 (Wed, 1 Aug 2007 23:41:33 -0400)
From: Frank Condello
On 1-Aug-07, at 10:58 PM, <email address removed> wrote:

> On Aug 02, 2007, at 02:50 UTC, Daniel Stenning wrote:
>
>> It seems that whenever I do a drag on a window, or some mouse action
>> that this thread gets frozen out. The same seems to apply if I
>> replace a thread with a loop as above with a timer. Somehow, doing a
>> GUI operation seems to "pause" the thread.
>
> Right. That's how it works.

RS could certainly make things work without blocking on Mac OS X,
though perhaps it requires using Cocoa controls (and maybe we'll get
those one day). I'm not sure about Linux, but on Windows things like
clicking a button won't block threads or timers, and if you make your
own controls out of Canvases threads and timers will keep running
even on Mac OS X - so there's definitely consistency problems to be
aware of.

For window drags, I have an AsyncDragWindow example available that
won't block threads/timers on Mac OS X 10.3 and up (better than
nothing):
<http://developer.chaoticbox.com/realbasic_classes.php>

Frank.
<http://developer.chaoticbox.com/>


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 05:20 (Thu, 02 Aug 2007 05:20:15 +0100)
From: Daniel Stenning
Briliant ! - just tried it out and works fine on my exaple. Thanks for that!

Is there any way of preventing resize from blocking too ?

Now if there only was an async button, async listbox,

On 2/8/07 04:41, "Frank Condello" <<email address removed>> wrote:

> For window drags, I have an AsyncDragWindow example available that
> won't block threads/timers on Mac OS X 10.3 and up (better than
> nothing):

Cheers,
Dan



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 04:53 (Thu, 02 Aug 2007 04:53:35 +0100)
From: Daniel Stenning
On 2/8/07 03:58, "<email address removed>" <<email address removed>> wrote:

> On Aug 02, 2007, at 02:50 UTC, Daniel Stenning wrote:
>
>> It seems that whenever I do a drag on a window, or some mouse action
>> that this thread gets frozen out. The same seems to apply if I
>> replace a thread with a loop as above with a timer. Somehow, doing a
>> GUI operation seems to "pause" the thread.
>
> Right. That's how it works.

Hmmm....

Quoting from the RB Language Reference verbatim:

"Threads execute code in the background, independent of the user
interface"

>> This is not what I would expect. The RB thread should be oblivious of
>> any mouse action in the main RB app thread.
>
> Your expectations require adjustment.

If so, then so does the Language reference.

>
> Cheers,
> - Joe
>
> --
> Joe Strout -- <email address removed>
> Strout Custom Solutions, LLC
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

Cheers,
Dan



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 05:44 (Thu, 2 Aug 2007 00:44:30 -0400)
From: Frank Condello
I couldn't see any way to prevent resizes from blocking, but if you
roll your own resize widget, buttons, etc., based on canvases you can
get things working pretty well. It's a PITA that the built-in native
controls block but as far as I can tell only RS can fix those.

Note that clicking the system menu will block as well - you can trap
clicks up there and set up a more graceful "pause" in some situations
but that's about it. I've got declares for that somewhere but none
handy at the moment...

Frank
<http://developer.chaoticbox.com/>

On 2-Aug-07, at 12:20 AM, Daniel Stenning wrote:

> Briliant ! - just tried it out and works fine on my exaple. Thanks
> for that!
>
> Is there any way of preventing resize from blocking too ?
>
> Now if there only was an async button, async listbox,
>
> On 2/8/07 04:41, "Frank Condello" <<email address removed>> wrote:
>
>> For window drags, I have an AsyncDragWindow example available that
>> won't block threads/timers on Mac OS X 10.3 and up (better than
>> nothing):
>
> Cheers,
> Dan


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 08:07 (Thu, 02 Aug 2007 08:07:43 +0100)
From: Daniel Stenning
Is there by any chance any existing fr for all this ? As you rightly say it
is a real PITA.

On 2/8/07 05:44, "Frank Condello" <<email address removed>> wrote:

> It's a PITA that the built-in native
> controls block but as far as I can tell only RS can fix those.

Cheers,
Dan



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 08:54 (Thu, 2 Aug 2007 03:54:38 -0400)
From: Frank Condello
A quick search brought up this 4-year-old FR:
<http://www.realsoftware.com/feedback/yqicxpdi>

Frank.
<http://developer.chaoticbox.com/>

On 2-Aug-07, at 3:07 AM, Daniel Stenning wrote:

> Is there by any chance any existing fr for all this ? As you
> rightly say it
> is a real PITA.
>
> On 2/8/07 05:44, "Frank Condello" <<email address removed>> wrote:
>
>> It's a PITA that the built-in native
>> controls block but as far as I can tell only RS can fix those.
>



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 12:37 (Thu, 2 Aug 2007 13:37:44 +0200)
From: Christian Schmitz
Daniel Stenning <<email address removed>> wrote:
> I know RB threads are sort of co-operative internally as opposed to true
> pre-emptive threads, but even so, I wouldn't expect GUI actions to lock out
> other RB threads - particularly since I gave the thread a high priority.

I think the CarbonEventsTimerMBS class fires its Action event even while
the mouse is down.

You can try that and call app.yieldtonextthread in the action event.

Gruß
Christian

-

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 14:47 (Thu, 02 Aug 2007 14:47:02 +0100)
From: Daniel Stenning
Excellent. I'll give it a go.

On 2/8/07 12:37, "Christian Schmitz" <<email address removed>> wrote:

> Daniel Stenning <<email address removed>> wrote:
>> I know RB threads are sort of co-operative internally as opposed to true
>> pre-emptive threads, but even so, I wouldn't expect GUI actions to lock out
>> other RB threads - particularly since I gave the thread a high priority.
>
> I think the CarbonEventsTimerMBS class fires its Action event even while
> the mouse is down.
>
> You can try that and call app.yieldtonextthread in the action event.
>
> Gruß
> Christian

Cheers,
Dan



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 15:10 (Thu, 2 Aug 2007 08:10:07 -0600)
From: joe strout.net
On Aug 02, 2007, at 03:53 UTC, Daniel Stenning wrote:

> Quoting from the RB Language Reference verbatim:
>
> "Threads execute code in the background, independent of the user
> interface"

Yeah, that's an oversimplification. Threads DO execute in the
background, independent of the main thread, which drives the user
interface. So, for example, code in a thread won't stop the user from
clicking buttons, using menus, typing into EditFields, and otherwise
interacting with the UI. That's what the LR means by this, and it is
in fact pretty much the whole point of putting long processing into a
Thread; if you do it in the main thread, then the UI is tied up and the
user can't do any of those things.

But the threads are cooperative, and when the system is tracking (say)
a menu selection, it's not cooperating; the main thread then blocks
other threads.

Any thread can block other threads if you try hard enough; for example,
put this into a Thread object and run it:

#pragma backgroundTasks false
do
loop

This creates an infinite loop that doesn't yield to other threads, so
they're all blocked.

The fact that threads can block each other does mean that they're not
truly "independent" in a strict sense -- but then, even if they
couldn't block each other, they wouldn't be fully independent, since
your processor can only do so much at once. But under normal,
non-blocking conditions, the threads do run independently, allowing the
user to interact with the UI.

Best,
- Joe

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 15:42 (Thu, 02 Aug 2007 10:42:50 -0400)
From: Chris Little
on 8/2/07 10:10 AM, <email address removed> at <email address removed> wrote:

> On Aug 02, 2007, at 03:53 UTC, Daniel Stenning wrote:
>
>> Quoting from the RB Language Reference verbatim:
>>
>> "Threads execute code in the background, independent of the user
>> interface"
>
> Yeah, that's an oversimplification. Threads DO execute in the
> background, independent of the main thread, which drives the user
> interface. So, for example, code in a thread won't stop the user from
> clicking buttons, using menus, typing into EditFields, and otherwise
> interacting with the UI. That's what the LR means by this, and it is
> in fact pretty much the whole point of putting long processing into a
> Thread; if you do it in the main thread, then the UI is tied up and the
> user can't do any of those things.
>
> But the threads are cooperative, and when the system is tracking (say)
> a menu selection, it's not cooperating; the main thread then blocks
> other threads.
>
> Any thread can block other threads if you try hard enough; for example,
> put this into a Thread object and run it:
>
> #pragma backgroundTasks false
> do
> loop
>
> This creates an infinite loop that doesn't yield to other threads, so
> they're all blocked.
>
> The fact that threads can block each other does mean that they're not
> truly "independent" in a strict sense -- but then, even if they
> couldn't block each other, they wouldn't be fully independent, since
> your processor can only do so much at once. But under normal,
> non-blocking conditions, the threads do run independently, allowing the
> user to interact with the UI.

Some of this blocking is caused by the Carbon runtime though. RS has said
that the switch to using Cocoa for the UI would fix the blocking of threads
while a menu was down for example.

Chris

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 16:18 (Thu, 02 Aug 2007 16:18:12 +0100)
From: Daniel Stenning
On 2/8/07 15:42, "Chris Little" <<email address removed>> wrote:

> Some of this blocking is caused by the Carbon runtime though. RS has said
> that the switch to using Cocoa for the UI would fix the blocking of threads
> while a menu was down for example.
>

I ok forward to that arrival. Do any people out there experience similar
blocking issues with the Windows XP Vista or Linux versions of RB ?.

For my purposes I need this resolved for OSX, and Windows XP/Vista.

Cheers,
Dan



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 16:40 (Thu, 02 Aug 2007 16:40:52 +0100)
From: Daniel Stenning
On 2/8/07 15:10, "<email address removed>" <<email address removed>> wrote:

> But the threads are cooperative, and when the system is tracking (say)
> a menu selection, it's not cooperating; the main thread then blocks
> other threads.

Other users have already pointed out ways that at least some of these issues
could be avoided by writing the framework differently for things like
dragging windows. Are there really OS API issues in OSX ( Carbon ) that
truly mean it is impossible to write a cooperative mechanism - say that
avoids blocking during a menu selection ?.

A quick scan through the Apple Developer web site reveals the following
tidbits :

"If you're working in the Carbon environment the first decision you have to
make is whether you can use preemptive threads or whether you must use
cooperative threads. Many Carbon calls are not available to preemptive
threads, even on Mac OS X. However, if you can use preemptive threads then
you should; it's difficult to integrate cooperative threads into a
well-behaved Mac OS X application."

And:

" If your Carbon application has to use cooperative threads, your only
choice is Thread Manager."

Are the blocking issues in RB OSX due to the fact that an RB app uses te
Carbon framework and thus is FORCED to only use co-operative threads ?. Is
the RB thread system totally specific to RB or does it use one of the many
existing threading models available on OS/X ?

Out of interest , how much difference would it make to have the RB framework
use the OS/X threading mechanism instead of RB's roll your own ?. Is this
too hard because of a lack of true pre-emptive thread-safety in RB ?.

I note also that apparently Leopard will add many threading and MP abilities
that would be useful for RB:

http://www.apple.com/macosx/leopard/technology/multicore.html

( particularly NSOperation and NSOperationQueue )

presumably we can get them once RB goes Cocoa...

Cheers,
Dan



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 19:05 (Thu, 2 Aug 2007 20:05:13 +0200)
From: Stefan

Am 02.08.2007 um 17:40 schrieb Daniel Stenning:

> I note also that apparently Leopard will add many threading and MP
> abilities
> that would be useful for RB:
>
> http://www.apple.com/macosx/leopard/technology/multicore.html
>
> ( particularly NSOperation and NSOperationQueue )
>
> presumably we can get them once RB goes Cocoa...

A switch from Carbon to Cocoa is somewhere between trivial to very
complex.
It depends, which and how much parts of Carbon you use and how well you
prepared for certain aspects.

Thus, only RS can expect how much work is necessary. As I see it,
since long,
Cocoa is Apple's favorite system.

Leopard will get - from the perspective of a coder - very nice. E.g.
Cocoa comes with fully automated memory management: No need to
allocate auto-release pools. Just allocate an object and forget about
it. Cocoa releases it if appropriate.

Questionable is the fact, if such like apps will run on pre-Leopard
systems
too.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 02.08.07 19:39 (Thu, 02 Aug 2007 14:39:46 -0400)
From: Chris Little
on 8/2/07 2:05 PM, Stefan at <email address removed> wrote:

> Leopard will get - from the perspective of a coder - very nice. E.g.
> Cocoa comes with fully automated memory management: No need to
> allocate auto-release pools. Just allocate an object and forget about
> it. Cocoa releases it if appropriate.
>
> Questionable is the fact, if such like apps will run on pre-Leopard
> systems
> too.

The answer would be no. Objective-C 2.0 requires Leopard.

Chris

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 16.08.07 07:03 (Thu, 16 Aug 2007 02:03:04 -0400)
From: Frank Condello
I'm dredging up this old thread with some updated info...

First, I've added a few words to the workaround field of "iyizlqrt"
<http://www.realsoftware.com/feedback/iyizlqrt>
Basically, for Mac OS X, this situation is entirely fixable - so it's
in REAL Software's hands, but if yer handy with declares it can also
be in your own hands...

I'll also note that the old "yqicxpdi" report (threads are blocked)
was closed as a duplicate of "zcdeyyhr" (gimme pre-emptive threads) -
but those reports are really unrelated. If anything "yqicxpdi" is a
duplicate "iyizlqrt" (above) but the comments have been move to the
unrelated feature request just confusing the matter and wrecking
people's watch lists. So vote again for "iyizlqrt" if you haven't
already 'cause as far as I can tell RS ignores "Request Changes"
comments...

Frank.
<http://developer.chaoticbox.com/>

On 2-Aug-07, at 4:34 AM, Daniel Stenning wrote:

> ... this contradicts the Language reference I have also
> added a new bug report for this here:
>
> http://www.realsoftware.com/feedback/viewreport.php?reportid=iyizlqrt
> ...

>>>
>>> On 2/8/07 08:54, "Frank Condello" <<email address removed>> wrote:
>>>
>>>> A quick search brought up this 4-year-old FR:
>>>> <http://www.realsoftware.com/feedback/yqicxpdi>



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 16.08.07 13:54 (Thu, 16 Aug 2007 13:54:05 +0100)
From: Daniel Stenning
Thanks for that Frank.

I don't recall seeing any solution for menu actions thread blocking. Is this
something RS should be able to fix too?. Is there any solution for this via
RB code in current RB?
The bit about using timers together with thread to ensure they don't block
seems a bit icky , but if that's the way to solve it with carbon then so be
it.

On 16/8/07 07:03, "Frank Condello" <<email address removed>> wrote:

> I'm dredging up this old thread with some updated info...
>
> First, I've added a few words to the workaround field of "iyizlqrt"
> <http://www.realsoftware.com/feedback/iyizlqrt>
> Basically, for Mac OS X, this situation is entirely fixable - so it's
> in REAL Software's hands, but if yer handy with declares it can also
> be in your own hands...
>
> I'll also note that the old "yqicxpdi" report (threads are blocked)
> was closed as a duplicate of "zcdeyyhr" (gimme pre-emptive threads) -
> but those reports are really unrelated. If anything "yqicxpdi" is a
> duplicate "iyizlqrt" (above) but the comments have been move to the
> unrelated feature request just confusing the matter and wrecking
> people's watch lists. So vote again for "iyizlqrt" if you haven't
> already 'cause as far as I can tell RS ignores "Request Changes"
> comments...
>
> Frank.
> <http://developer.chaoticbox.com/>
> On 2-Aug-07, at 4:34 AM, Daniel Stenning wrote:
>
>> ... this contradicts the Language reference I have also
>> added a new bug report for this here:
>>
>> http://www.realsoftware.com/feedback/viewreport.php?reportid=iyizlqrt
>> ...
>
>>>>
>>>> On 2/8/07 08:54, "Frank Condello" <<email address removed>> wrote:
>>>>
>>>>> A quick search brought up this 4-year-old FR:
>>>>> <http://www.realsoftware.com/feedback/yqicxpdi>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

Cheers,
Dan



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 16.08.07 18:37 (Thu, 16 Aug 2007 13:37:04 -0400)
From: Frank Condello
The "yielding" Carbon timer lets threads run when menus are down (at
least in my limited testing it did), and as I pointed out in the
report this is the Apple-recommended way to go about it. There may be
some issues however, particularly if you're using Quickdraw, since
the current port might go out of whack. Regardless, this appears to
be workable with declares in most situations.

Frank.
<http://developer.chaoticbox.com/>

On 16-Aug-07, at 8:54 AM, Daniel Stenning wrote:

> Thanks for that Frank.
>
> I don't recall seeing any solution for menu actions thread
> blocking. Is this
> something RS should be able to fix too?. Is there any solution for
> this via
> RB code in current RB?
> The bit about using timers together with thread to ensure they
> don't block
> seems a bit icky , but if that's the way to solve it with carbon
> then so be
> it.
>
> On 16/8/07 07:03, "Frank Condello" <<email address removed>> wrote:
>
>> I'm dredging up this old thread with some updated info...
>>
>> First, I've added a few words to the workaround field of "iyizlqrt"
>> <http://www.realsoftware.com/feedback/iyizlqrt>
>> Basically, for Mac OS X, this situation is entirely fixable - so it's
>> in REAL Software's hands, but if yer handy with declares it can also
>> be in your own hands...
>>
>> I'll also note that the old "yqicxpdi" report (threads are blocked)
>> was closed as a duplicate of "zcdeyyhr" (gimme pre-emptive threads) -
>> but those reports are really unrelated. If anything "yqicxpdi" is a
>> duplicate "iyizlqrt" (above) but the comments have been move to the
>> unrelated feature request just confusing the matter and wrecking
>> people's watch lists. So vote again for "iyizlqrt" if you haven't
>> already 'cause as far as I can tell RS ignores "Request Changes"
>> comments...
>>
>> On 2-Aug-07, at 4:34 AM, Daniel Stenning wrote:
>>
>>> ... this contradicts the Language reference I have also
>>> added a new bug report for this here:
>>>
>>> http://www.realsoftware.com/feedback/viewreport.php?
>>> reportid=iyizlqrt
>>> ...
>>
>>>>>
>>>>> On 2/8/07 08:54, "Frank Condello" <<email address removed>>
>>>>> wrote:
>>>>>
>>>>>> A quick search brought up this 4-year-old FR:
>>>>>> <http://www.realsoftware.com/feedback/yqicxpdi>


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 17.08.07 00:01 (Thu, 16 Aug 2007 19:01:28 -0400)
From: Frank Condello
Ugh, "iyizlqrt" just got evaluated as "This is a bug with the
documentation, not with the implementation." Note to future bug
submitters: NEVER QUOTE THE RB DOCS - hell, avoid reading them if you
can.

So lets recap:

"iyizlqrt" has been written off 'cause it mentioned the language
reference, the original bug report "yqicxpdi" "Thread blocking on GUI
interactions" is closed as a duplicate of "zcdeyyhr" which asks "add
preemptive threads to win/osx" yet these are two entirely separate
issues from a user's perspective. To top that off, the evaluation for
"zcdeyyhr" suggests you "can call any thread library you like using
the Declare statement". Ugh, again. RS might as well pre-evaluate
every request with "DIY jackass!"

I really wish RS would _listen_ to its users and not just take the
path-of-least-work to close bug reports. I'm so, so tired of this run-
around crap...

Frank.
<http://developer.chaoticbox.com/>

On 16-Aug-07, at 1:37 PM, Frank Condello wrote:

> The "yielding" Carbon timer lets threads run when menus are down (at
> least in my limited testing it did), and as I pointed out in the
> report this is the Apple-recommended way to go about it. There may be
> some issues however, particularly if you're using Quickdraw, since
> the current port might go out of whack. Regardless, this appears to
> be workable with declares in most situations.
>
> Frank.
> <http://developer.chaoticbox.com/>
> On 16-Aug-07, at 8:54 AM, Daniel Stenning wrote:
>
>> Thanks for that Frank.
>>
>> I don't recall seeing any solution for menu actions thread
>> blocking. Is this
>> something RS should be able to fix too?. Is there any solution for
>> this via
>> RB code in current RB?
>> The bit about using timers together with thread to ensure they
>> don't block
>> seems a bit icky , but if that's the way to solve it with carbon
>> then so be
>> it.
>>
>> On 16/8/07 07:03, "Frank Condello" <<email address removed>> wrote:
>>
>>> I'm dredging up this old thread with some updated info...
>>>
>>> First, I've added a few words to the workaround field of "iyizlqrt"
>>> <http://www.realsoftware.com/feedback/iyizlqrt>
>>> Basically, for Mac OS X, this situation is entirely fixable - so
>>> it's
>>> in REAL Software's hands, but if yer handy with declares it can also
>>> be in your own hands...
>>>
>>> I'll also note that the old "yqicxpdi" report (threads are blocked)
>>> was closed as a duplicate of "zcdeyyhr" (gimme pre-emptive
>>> threads) -
>>> but those reports are really unrelated. If anything "yqicxpdi" is a
>>> duplicate "iyizlqrt" (above) but the comments have been move to the
>>> unrelated feature request just confusing the matter and wrecking
>>> people's watch lists. So vote again for "iyizlqrt" if you haven't
>>> already 'cause as far as I can tell RS ignores "Request Changes"
>>> comments...
>>>
>>> On 2-Aug-07, at 4:34 AM, Daniel Stenning wrote:
>>>
>>>> ... this contradicts the Language reference I have also
>>>> added a new bug report for this here:
>>>>
>>>> http://www.realsoftware.com/feedback/viewreport.php?
>>>> reportid=iyizlqrt
>>>> ...
>>>
>>>>>>
>>>>>> On 2/8/07 08:54, "Frank Condello" <<email address removed>>
>>>>>> wrote:
>>>>>>
>>>>>>> A quick search brought up this 4-year-old FR:
>>>>>>> <http://www.realsoftware.com/feedback/yqicxpdi>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: RB thread "paused" whenever a GUI action such as window dragging or resize occurs
Date: 17.08.07 02:50 (Fri, 17 Aug 2007 02:50:58 +0100)
From: Daniel Stenning
I second all that. What a total "cop out".

Users provide feedback to make RB A better product, something that makes
programming easier, and instead we get the lame fob-off that it was a
documentation error. Maybe it was - but the fact remains that it is not
exactly unreasonable to expect a thread to behave in a manner independent of
other threads or GUI actions. Why else bother to program in a thread at all?


On 17/8/07 00:01, "Frank Condello" <<email address removed>> wrote:

> Ugh, "iyizlqrt" just got evaluated as "This is a bug with the
> documentation, not with the implementation." Note to future bug
> submitters: NEVER QUOTE THE RB DOCS - hell, avoid reading them if you
> can.
>
> So lets recap:
>
> "iyizlqrt" has been written off 'cause it mentioned the language
> reference, the original bug report "yqicxpdi" "Thread blocking on GUI
> interactions" is closed as a duplicate of "zcdeyyhr" which asks "add
> preemptive threads to win/osx" yet these are two entirely separate
> issues from a user's perspective. To top that off, the evaluation for
> "zcdeyyhr" suggests you "can call any thread library you like using
> the Declare statement". Ugh, again. RS might as well pre-evaluate
> every request with "DIY jackass!"
>
> I really wish RS would _listen_ to its users and not just take the
> path-of-least-work to close bug reports. I'm so, so tired of this run-
> around crap...
>
> Frank.
> <http://developer.chaoticbox.com/>
> On 16-Aug-07, at 1:37 PM, Frank Condello wrote:
>
>> The "yielding" Carbon timer lets threads run when menus are down (at
>> least in my limited testing it did), and as I pointed out in the
>> report this is the Apple-recommended way to go about it. There may be
>> some issues however, particularly if you're using Quickdraw, since
>> the current port might go out of whack. Regardless, this appears to
>> be workable with declares in most situations.
>>
>> Frank.
>> <http://developer.chaoticbox.com/>
>>
>> On 16-Aug-07, at 8:54 AM, Daniel Stenning wrote:
>>
>>> Thanks for that Frank.
>>>
>>> I don't recall seeing any solution for menu actions thread
>>> blocking. Is this
>>> something RS should be able to fix too?. Is there any solution for
>>> this via
>>> RB code in current RB?
>>> The bit about using timers together with thread to ensure they
>>> don't block
>>> seems a bit icky , but if that's the way to solve it with carbon
>>> then so be
>>> it.
>>>
>>> On 16/8/07 07:03, "Frank Condello" <<email address removed>> wrote:
>>>
>>>> I'm dredging up this old thread with some updated info...
>>>>
>>>> First, I've added a few words to the workaround field of "iyizlqrt"
>>>> <http://www.realsoftware.com/feedback/iyizlqrt>
>>>> Basically, for Mac OS X, this situation is entirely fixable - so
>>>> it's
>>>> in REAL Software's hands, but if yer handy with declares it can also
>>>> be in your own hands...
>>>>
>>>> I'll also note that the old "yqicxpdi" report (threads are blocked)
>>>> was closed as a duplicate of "zcdeyyhr" (gimme pre-emptive
>>>> threads) -
>>>> but those reports are really unrelated. If anything "yqicxpdi" is a
>>>> duplicate "iyizlqrt" (above) but the comments have been move to the
>>>> unrelated feature request just confusing the matter and wrecking
>>>> people's watch lists. So vote again for "iyizlqrt" if you haven't
>>>> already 'cause as far as I can tell RS ignores "Request Changes"
>>>> comments...
>>>>
>>>> On 2-Aug-07, at 4:34 AM, Daniel Stenning wrote:
>>>>
>>>>> ... this contradicts the Language reference I have also
>>>>> added a new bug report for this here:
>>>>>
>>>>> http://www.realsoftware.com/feedback/viewreport.php?
>>>>> reportid=iyizlqrt
>>>>> ...
>>>>
>>>>>>>
>>>>>>> On 2/8/07 08:54, "Frank Condello" <<email address removed>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> A quick search brought up this 4-year-old FR:
>>>>>>>> <http://www.realsoftware.com/feedback/yqicxpdi>
>>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

Cheers,
Dan



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>