[quote=492215:@Christian Schmitz]I think you may solve this by doing the asynchronous mode.
See CURLSMultiMBS class, where you can add CURLSMBS and then run a timer with 10ms or so delay and call Perform on it.
When a CURLSMBS is finished, it raises the TransferFinished event on CURLSMultiMBS and Finished event in CURLSMBS, so you can process result there.[/quote]
Well Ill be… I didnt even notice this class existed. Yes, its exactly what Im looking for.
To get respect from a wider audience Xojo Inc needs to sweat the details more .
One should not have to use a plugin to get reliable functionality that is supposed to be part of the framework. And that is even more important for “Citizen developers” than Pros who can figure what tech problem is and know they need a plugin (and can justify the cost)
Well, as usually 90% are happy with the built in functionality and the other 10% can get more via plugin.
Or, 65% are happy, 10% use plugins, and 25% abandon it for a more stable solution …
I’ve had a lot of luck learning React in the last couple weeks and am beginning to find myself in that last category.
The solution is on the roadmap:
Multicore - An easy way to utilize multiple cores in your Desktop/Console applications. Web support coming after initial release.
And such code there, must have a good 2 way interprocess communication / shared memory / synchronization features, to share data and events. So your code in the main thread will not be blocked.
[quote=492248:@Rick Araujo]The solution is on the roadmap:
Multicore - An easy way to utilize multiple cores in your Desktop/Console applications. Web support coming after initial release.
And such code there, must have a good 2 way interprocess communication / shared memory / synchronization features, to share data and events. So your code in the main thread will not be blocked.[/quote]
Maybe some day I could use it. But I can’t today, and I can’t count on it working reliably even when I can use it. I’d love to be wrong, but it’s safer to assume it’ll have showstopper problems.
I clearly wasn’t referring to your case, as you already abandoned the platform for React. NO ONE will have any good solution until “multicore” + what I said comes, and everybody knows it’s not today, better… not in many (or many, many,) weeks.
Stop putting words in my mouth.
[quote=492235:@Thom McGrath] @Tim Jones Or, 65% are happy, 10% use plugins, and 25% abandon it for a more stable solution …
I’ve had a lot of luck learning React in the last couple weeks and am beginning to find myself in that last category.[/quote]
I’m sorry, seems I misread you, as you misread me.
@Rick Araujo - keep in mind that all we can do as professional users is to use what is available TODAY. It doesn’t matter what Xojo have promised for Xojo 2021r3 because we can’t use that. This is why your first comment to Thom above is off the target - he (and most of us) are talking about what we’re dealing with TODAY in using Xojo to develop commercial applications. The issue that we are discussing and facing is that many features and functions that are (or should be) built in to the Xojo Framework are poorly implemented, have serious runtime issues, or are not even there to begin with.
@Tim Jones , as one of the of the ex very vocal requesters of preemptive multitreading and multi core use for Xojo, for almost 10 years, until giving up, I know what we are dealing TODAY, we are dealing with the same old problem, that NOW there’s one workaround promised for some time in a NEAR FUTURE as they said. I tried to put on the table key features that if not coming now with such workaround, will make it a kind of useless feature. I don’t want just a shell+IPCsocket repacked, as that I have today.
Well, for Xojo the last 20 years, it has been the same rules:
- Xojo Inc. may not align their priorities with your wishes.
- You can only sell to your customers what exists today.
- Roadmap may change and some things do never ship.
- Don’t wait for an upcoming feature. It will take longer and needs one or two quarters to get bugs fixed.
- Buying an add-on, source code or a plugin, may get you a desired feature today.
[quote=492340:@Christian Schmitz]Well, for Xojo the last 20 years, it has been the same rules:
Xojo Inc. may not align their priorities with your wishes.
1. You can only sell to your customers what exists today.
2. Roadmap may change and some things do never ship.
3. Don't wait for an upcoming feature. It will take longer and needs one or two quarters to get bugs fixed.
4. Buying an add-on, source code or a plugin, [b]may[/b] get you a desired feature today.[/quote]
1 and 3, true.
2 You can change items for better, but you’ll deal with disappointing people with broken promises if not delivered.
4 Is more a sales pitch.
Also there’s:
-5. Write yourself an alternative solution.
-6. If your tool is too limited for your job, maybe you need another tool.
True, but I and others make a living on providing the missing parts for Xojo developers.
I know and I do support your excellent job doing it.
Amen. Someone message me when we get lambdas, generics, and Nullable object wrappers for the primitives…
(What’s even more frustrating is things like that last one would take little to no effort)
What Christian’s asking for in the original post should definitely be considered a default feature - especially if we’re dependent on the existing, mostly cooperative threading model.
And I’m very thankful for your solutions. But here’s an example of something I shouldn’t need to get via a plugin:
The macOS StatusMenu:
Since the TaskBar is built in to Xojo’s Framework for Linux and Windows, why isn’t the StatusMenu (the same feature under macOS) implemented? It’s been an outstanding request since 2006 at least: <https://xojo.com/issue/1792>
As Rick describes - How long have we been requesting true, preemptive threading? <https://xojo.com/issue/9515>, <https://xojo.com/issue/1106>, and others.
cough framework needs to be thread safe cough
Xojo is no rust but is a bit rusty