for ias Integer =0to 1000000
dim ras Double = rnd
That code will not actually run in 5.5.5; I assume you mean:
Dim i as integer
Dim r as double
for i = 0 to 1000000
r = rnd
Yes, this particle code, in the action event of a button, generates a watchcursor without the pragama, and with the pragma inserted no watchcursor is generated. The watchcursor is generated on both Classic (9.0) and Classic Mode (9.2.2).
So I removed all my code from the thread and inserted into the action event of a button, including the DisableAutoWaitCursor pragma. The watchcursor is still generated on Classic (9.0). The watchcursor is never generated on Classic mode (9.2.2) regardless of if the pragma is included or not. X and XP are also not effected. There is no other code executing at the same time.
The problem here is that the above loop does not emulate the code I am using. Although there are a couple tiny loops (probably can’t measure the time they take as they’re too small) 99.9% of the code consists of series of If-ElseIf-End statements, case statements, and references to control properties. Many of the If statements do not have a simple format, for example
If condition and condition and condition then
If condition and condition or condition and condition or condition and condition then
If condition and condition and condition or condition then
Probably the best example of what is being done would be Adobe Illustrator’s multi-panel save preview window in which say 4 different versions of a document can be viewed in mutli-paned window at once. In my application the processor intense code performs a series of tests, sets control and window properties based on computations, and then each object that is to be modified is updated at the end of the code block. Adobe illustrator’s preview window is slightly different in that it computes and illustrates one configuration at a time (showing a progressbar for each preview pane) whereas mine first computes all changes and then updates everything.
So far the only way to get rid of the watchcursor on Classic is to place the code inside a thread; however, running the code in a thread on X makes it twice a slow so I only way I can see to overcome this to use the thread for Classic and Classic Mode and use nonthreaded code for X and XP, which means I must duplicate 1,100 lines of code.
This is really weird though that the same thread runs slower on a faster processor; it also runs slower in X than in Classic mode when both are runing on the same machine.
Which means that threads won't yield any time back to any thread, which essentially negates the usefulness of the thread. You shouldn't be disabling background tasks in threads.
According to 5.5.5’s LR #Pragma Directives: DisableBackgroundTasks states:
“It prevents REALbasic from calling the WaitNextEvent toolbox routine, so it never yields time ot any other applications. It therefore, can speed up processor-intense operations but prevents REALbasic from displaying the Watch cursor, may halt normal background updating of interface elements, and prevents other threads from executing.”
I don’t see any information pertaining to threads in this. Please note I am only running one thread at a time - the application only contains one instance of a thread class in the main window. Are you saying that because this is used the main application thread will not yield time to the instance of the thread class in the main window - if though the main application thread is not performing any tasks.
No. I mean the Thread.Priority property on the thread class. Priority has nothing to do with yielding to other applications in the system and everything to do with yielding to other threads in your application.
Thanks for the links I saved them as pdf’s); however, a good percentage of the articles do not apply to RB 5.5.5 as the thread class has no priority property and the app class has no yieldtonextthread property, etc...