Again Threads and UI-tasks

[quote=6988:@Massimo Valle]I agree. A library or plugin could better handle this.
However, I think Xojo Inc. should try to offer an official workaround to this problem. Too many people need to access UI from threads and, in lack of an official library/plugin/mechanism every one is coming with his own solution which, sometimes, is worst than the problem it solves.

I’d appreciate if Xojo will provide a library or plugin for this, even if not officially supported. At least there would be one official solution.
[/quote]

They have a lot on their plate. I actually do not see this as a problem. I see it as they’ve given correct advice about using threads with non-thread-safe libraries and developers have made it a problem, basically because they want to negotiate about where the line of thread-safety is rather than understand the underlying issue.

In fact, there may be more than one “solution” to this developer-created “problem”. The obvious one relies on blocking. A less obvious one might queue up UI manipulations. That might be more appropriate for things link progress bars and animations.

Perhaps an example is in order. But I don’t think we’re well-served by a solution to a problem of our own making.

Even though ctrl2 is declared as a Label, it IsA cLabel, so most people would expect the cLabel property to be used.

It’s a gotcha because if you did the same thing with a method (say SetString), the subclass method would be used rather than the superclass method.

[quote=7046:@Paul Lefebvre]Even though ctrl2 is declared as a Label, it IsA cLabel, so most people would expect the cLabel property to be used.

It’s a gotcha because if you did the same thing with a method (say SetString), the subclass method would be used rather than the superclass method.[/quote]

I agree : I think using this does not argue that “Thread-safe subclasses” is a bad idea per se, but rather that “the language could use some changes in how virtual getters/setters work” which is rather a separate issue. This Gotcha will crop up anytime you use subclassed controls, threads or no.

Properties are not virtual - NO properties computed or not - so computed property getters & setters are not virtual
If you want / need virtual getters & setters use method pairs

[quote=7054:@Norman Palardy]Properties are not virtual - NO properties computed or not - so computed property getters & setters are not virtual
If you want / need virtual getters & setters use method pairs[/quote]

If a sub-class has Methods which are the same name as a superclasses Computed Property getter and setter, will the Methods be called virtually?

e.g. if instead of using

Caption.Get as string return mCaption Caption.Set(value as string) mCapiton = value UIUpdateRequest

I used this:

  Caption as string
      return mCaption
  Caption (assigns value as string)
      mCapiton = value
      UIUpdateRequest

Would this work to virtually override the superclass properties?

[quote=7062:@Michael Diehr]If a sub-class has Methods which are the same name as a superclasses Computed Property getter and setter, will the Methods be called virtually?

e.g. if instead of using

Caption.Get as string return mCaption Caption.Set(value as string) mCapiton = value UIUpdateRequest

I used this:

  Caption as string
      return mCaption
  Caption (assigns value as string)
      mCapiton = value
      UIUpdateRequest

Would this work to virtually override the superclass properties?[/quote]

Unlikely and you’d probably get a warning about shadowing properties with a method

[quote=7064:@dave duke]Well, to be honest I think a lot of the above is way ahead of any newbie being able to implement it, and as updating the interface in a thread is an obvious requirement. There should be an easier solution to hide the complexity of the problem. This question comes up again and again in threads and that means people are trying to do it and need a simpler / easier / less technical solution.
I vote that RS remove the complexity of updating the UI and accessing sessions in a thread, or a plugin should be developed.
This would make RS much easier for newbies and easier to maintain code. If there is a solution out there for these problems it needs to be wrapped into a plugin or part of the framework so new users don’t need to have advanced knowledge of RS to use it.[/quote]

Agreed. It makes my brain hurt thinking about some of the gyrations being talked about.

That’s why I believe that, at one point, Xojo Inc. will have to find a trade off for this.

And then everyone will complain when they pick the wrong trade-off. Look, threads are difficult. If you take a platform framework that has underlying thread-safety issues and try to graft thread safety onto it, you’re likely to end up with something where the convenience of the thread model is diminished by the threads sitting around, waiting for synchronization. Threads are complicated. You’re way better off understanding the issues (and not fighting them) than pretending they don’t exist.

Real world experience: I’ve been working on making my Carbon app fully happy with Cocoa / Xojo’s thread rules. So far I’ve refactored two big chunks of code.

  • For the first one, I broke my thread up into multiple pieces, adding timers which would call -begin and -finished routines (outside the thread) to do UI. It works, and was moderately difficult. Looking at the code I ended up with, the program flow is much harder to trace. I suspect when I come back to it in a year, it will be harder to maintain.

  • For the second cone, I took a different tact: I left the threaded code exactly as is, and swapped in my thread-safe controls (described above). It works, was very easy to do, and my belief is that in a year when I come back to this code, it will be easier to maintain.

Everyone codes differently, but I can say that in at least one real-world example, I’m a big fan of “thread-safe-control-dropins” and not so big a fan of “refactoring threaded code into threads, timers, and state-machines”, at least when porting old code.

If I were designing a new app from scratch, the tradeoff could be different.

And this is not even a WE app!

Updating the UI from a thread is very simple - but it does require a VERY LOW LEVEL knowledge of OOP.

Threads require a timer to update the UI. The timer action event can be a method of the thread if addhandler is used. So add a property to your thread called UIUpdate AS Timer. Add a method to your thread UIRefresh with a Parameter Sender As Timer. In this method you update the UI. In the constructor you instantiate the timer & add the handler pointing at UIRefresh, set the mode & period and away you go.

Very not hard! Perhaps I could sell a UIThread control if Jon Ogden hadn’t already taken this to the next level!

Come on guys it’s a rule applied by Apple that RS have to obey & therefore you too!

while OT in this thread (no pun intended :wink: for being more responsive to the user in WE apps there is a FR in Feedback: <https://xojo.com/issue/19486> Feel free to add your comments

[quote=7299:@Wayne Golding]Updating the UI from a thread is very simple - but it does require a VERY LOW LEVEL knowledge of OOP.

Threads require a timer to update the UI. The timer action event can be a method of the thread if addhandler is used. So add a property to your thread called UIUpdate AS Timer. Add a method to your thread UIRefresh with a Parameter Sender As Timer. In this method you update the UI. In the constructor you instantiate the timer & add the handler pointing at UIRefresh, set the mode & period and away you go.

Very not hard! Perhaps I could sell a UIThread control if Jon Ogden hadn’t already taken this to the next level!

Come on guys it’s a rule applied by Apple that RS have to obey & therefore you too![/quote]

Wayne, you appear to have posted without reading the thread you were commenting on. That was already discussed above. :slight_smile: The question being discussed is whether it makes sense for RS to build these thread-safe features into some of the controls of the framework, vs. expecting users to reinvent the wheel, vs. having a third-party package.

[quote=7299:@Wayne Golding]Updating the UI from a thread is very simple - but it does require a VERY LOW LEVEL knowledge of OOP.

Threads require a timer to update the UI. The timer action event can be a method of the thread if addhandler is used. So add a property to your thread called UIUpdate AS Timer. Add a method to your thread UIRefresh with a Parameter Sender As Timer. In this method you update the UI. In the constructor you instantiate the timer & add the handler pointing at UIRefresh, set the mode & period and away you go.

Very not hard! Perhaps I could sell a UIThread control if Jon Ogden hadn’t already taken this to the next level!

Come on guys it’s a rule applied by Apple that RS have to obey & therefore you too![/quote]

Wayne, you seem to have posted without reading the thread you were commenting on. That was already discussed well above. :slight_smile: The question being discussed now is whether it makes sense for RS to build these thread-safe features into some of the controls of the framework, vs. expecting users to reinvent the wheel, vs. having a third-party package.

Haha - ok, now I’ve double-posted. Is the xojo forum server acting up today?

I lived that too. Before clicking POST, select all and copy for safety. Then Click. Sometimes you see an error. Two options: Try again and refresh. Click refresh! Probably it will just work. If not, create a new post and paste your clipboard copy. :slight_smile: