What's behind this error msg?

DIM intStartPage as Int64 = CDbl(txtSettingsStartPage.text) DIM intStopPage as Int64 = (CDbl(txtSettingsStopPage.text)-1) * 10

DIM intStartPage as Integer = Val(txtSettingsStartPage.text) DIM intStopPage as Integer = (Val(txtSettingsStopPage.text)-1) * 10

Error message goes:

This code used to work before. The second code is just a rewriting of the first code…
Actually, I’m not “attempting to manipulate the user interface element”, instead, just taking the number saved in that place…

[quote=55614:@Jakob Krabbe] DIM intStartPage as Int64 = CDbl(txtSettingsStartPage.text) DIM intStopPage as Int64 = (CDbl(txtSettingsStopPage.text)-1) * 10

DIM intStartPage as Integer = Val(txtSettingsStartPage.text) DIM intStopPage as Integer = (Val(txtSettingsStopPage.text)-1) * 10

Error message goes:

This code used to work before. The second code is just a rewriting of the first code…
Actually, I’m not “attempting to manipulate the user interface element”, instead, just taking the number saved in that place…[/quote]

If this is in a thread READING or WRITING any built in property of a UI element will cause this error.
It’s not allowed.

Thank you for taking the time to answer the question!
The above fields are used for these settings.
I wonder:

  1. I used these things earlier and then it was not a problem, the same procedure.
  2. How shall I solve it this time!? How else would settings be used in a software?

Older versions of XOJO allowed this practice. the current version now enforces this edict.

All right.
How do you solve it? How do you use settings in Xojo these days, then?


I could think of one solution. It is to use local variables and store the data in these as well as in the editfields. But also, these procedure really bothers me, because it is against my principles, to store the same data more than in one place. It is really against all kind of common sense as I see it. Documentation is wider, the opportunity for misunderstanding is wider, the code itself is larger without any greater improvement…

I’m sure there is a good and an intelligent reason for this “new” procedure! Please tell me what it is as my fantasy is not bright and wide enough to see the great potential!

This take care of the settings. It’s a working solution…

[code]
’ ## LOAD SETTINGS
intStartPage = CDbl(txtSettingsStartPage.text)
intStopPage = (CDbl(txtSettingsStopPage.text)-1) * 10

// Let’s get to work…
threadScan.run[/code]

But then, the feedback and error checking is a dark chapter!!
This is NOT working any more!!

FOR j = 0 TO UBound(arrSERP, 2)-1 me.sleep(500, false) 'txtResult.text = txtResult.text + "URL: " + arrSERP(0,j) + " -- Keyword = " + arrSERP(1,j) + EndOfLine 'txtResult.text = txtResult.text +str(j) + EndOfLine

What kind of technique do you use to get feedback from the loops in the thread!?
For me, these things were kind of neat and useful…!

I don’t know, I think this is it!

[quote]There may be times where you want to update the user interface with something that has been processed in the thread. The way to do this is to have the user interface request the information from the thread.

The simplest technique is to have a Timer on the Window periodically checks a property on the Thread. The Timer then uses this information to update the UI. [/quote]
http://documentation.xojo.com/index.php/Thread

I will take the time to fiddle with the Timer to see if I can unbutton the secrets of UIExeptions!
Copy/paste was not working this time…!!

Yes, Timer is the solution. Let the thread alter a global variable, let the timer write it into the GUI element.

http://documentation.xojo.com/index.php/Thread

Thank you!! Based on the code on this page, that’s exactly what I did! It actually worked on the first attempt…! (It’s a rare feature!!)
Now it’s all working! However, I’m still waiting with great interest why the thread itself couldn’t read/write to the user interface… I’m sure there is a good reason! Eventually I will also understand!!

Thank you!

Bottom line, the UI isn’t thread-safe. Accessing UI elements from a thread will produce infrequent, intermittent, hard to reproduce errors.

Out of curiosity I did a little googling and confirmed my suspicions (I think).

Cocoa, Windows and Linux all do their UI work from a main thread, or in windows it is from the same thread that created to UI element. In Cocoa and Windows there seems to be certain situations where the OS runs a separate rendering thread for things like animating a progressbar or a smooth window resize (I’m guessing). There are ways to lock the UI and access it from another thread (maybe), but it looks messy, and doing so for each platform for every possible control/property/event/etc would be a huge undertaking and would probably result in horrible performance. Of course I’m going with a 10 minute Google session here. Perhaps the Xojo engineers could clarify it better…

Here’s what I’m looking at.
Apple
Windows
Linux

[quote=56281:@jim mckay]Out of curiosity I did a little googling and confirmed my suspicions (I think).

Cocoa, Windows and Linux all do their UI work from a main thread, or in windows it is from the same thread that created to UI element. In Cocoa and Windows there seems to be certain situations where the OS runs a separate rendering thread for things like animating a progressbar or a smooth window resize (I’m guessing). There are ways to lock the UI and access it from another thread (maybe), but it looks messy, and doing so for each platform for every possible control/property/event/etc would be a huge undertaking and would probably result in horrible performance. Of course I’m going with a 10 minute Google session here. Perhaps the Xojo engineers could clarify it better…
[/quote]
You’ve pretty much hit the nail on the head.
In one beta we did have a way to push things to the main thread so you could use threads & access UI and the performance was, as expected, horrendous.
Trying to do it in a safe, reliable, non-performance killing generic way across platforms just isn’t plausible.