Threading library for optimising compiler

[Elrick]

I apologise for my poor descriptions, i'm just bad english-speaker, so i'm trying to write as short as possible messages to make as less as possible mistakes :-) Yes this code works without an errors, but it works from the second-third time... When i press the button for the first time, there is always "no response received" inscription...

[agraham]

Originally Posted by Elrick

Yes this code works without an errors,

Good. You need to keep that error trapping in place.

but it works from the second-third time... When i press the button for the first time, there is always "no response received" inscription...

That cannot be anything to do with the threading library. More likely it is something in your device IP stack that causes the initial delay. Try increasing your HTTP timeout.

[Elrick]

omg! I have written timeout 3000 instead of 30000! This is the main error :-) Now all works fine, thank you very much, agraham, for this fantastic library and for you help in answering to my stupid questions :-)

[agraham]

Originally Posted by Elrick

my stupid questions :-)

No question is a stupid question if the asker really doesn't know the answer to it

[agraham]

Source code for dll merging posted in first post.

[TWELVE]

Hello agraham,

i tested a bit with your threading lib.I just call a sub as a thread, which appears to work fine.But i'm missing some responses from my sub.All my code parts are writing messages in a console.This is used as a status display and also for debugging purposes.The code is just calling a sub, which does log the message to the console control and also to a log file.The "console printing" sub is using a textbox control for the output, which is under the control of the main gui program.

Questions:

- what's wrong here ?
- Can i call a sub from a sub which has been started as a thread or not ?
- if it's ok to call a sub from a threaded sub, can the called sub access the controls of the main gui program ?
- if not, how can i work around this ?



cheers

TWELVE

[agraham]

Originally Posted by TWELVE

- what's wrong here ?

I don't know!

Can i call a sub from a sub which has been started as a thread or not ?

Yes, there should be no problem unless you also call that Sub from the main program or another thread. Keep thread code strictly segregated from other code.

if it's ok to call a sub from a threaded sub, can the called sub access the controls of the main gui program ?

No. Please read carefully the Thread Pitfalls page of the help. Especially the GUI operations section.

if not, how can i work around this ?

Use FireThreadEvent or FireDebugEvent to "call" your subs that manipulate GUI controls. They are provided as a safe path to the the GUI thread. You can only safely manipulate GUI controls in the main thread or in these events or Subs called by them. If you need multiple different operations then distinguish them in the event by setting a Global variable in the thread and doing a Select.... Case in the event.

[TWELVE]

Hi agraham,

thx for your reply.

I read the threading lib manual carefully, also the pitfalls section, but this was only talking about it would be unsafe to manipulate GUI elements, not it would be impossible.So for me it was not clear that i don't even have access to the GUI controls.

I tested with the Thread_ThreadEvent, which worked fineso far.However, i need to rework the code to have it communicating with the GUI.Furthermore the desktop simulation is throwing two error messages per thread call:

Library running in legacy mode.
Start, RunLock and Join are unavailable.

Start
Not available in legacy mode.

That is really impacting me because it renders the desktop emu nearly useless, unless i confirm 2 error boxes every second or so - depending on how often the thread is being called.

What is the reason for these errors ? Has the desktop lib/version only limited functionality ? Is it possible to suppress these error messages..?



kind regards

TWELVE

[agraham]

Originally Posted by TWELVE

would be unsafe to manipulate GUI elements, not it would be impossible.

Unsafe means don't do it because bad things can happen!

What is the reason for these errors ? Has the desktop lib/version only limited functionality ? Is it possible to suppress these error messages..?

They are not errors. This is explained this in the the "Thread debugging" section of the help. Please re-read it. As the first line says "Threads may only be used in optimised compiled Basic4PPC applications". That section of help documents the differences between optimised and legacy operations and the demo app shows how to ameliorate some of those differences.

[agraham]

Version 1.3 that understands Basic4ppc version 6.50 and later module prefixes now available in the first post of this thread.