At 08:48 PM 11/3/2006, you wrote:
> As a usual VB user, all this seems funny to me in this day of age.
> VB seems very pre-emptive multi-tasking, whereas RB seems more like
> 16-Windows, where one thing MUST come after the other.
Not so. I think the problem here is that REALbasic uses cooperative
threads, and your dylib cannot cooperate with Rb.
Are there rules about that? Why can't it cooperate?
If you wrote the library, then it would be possible to reimplement
it so that it could
cooperate with Rb by breaking long tasks into a sequence of shorter
tasks that could be called from Rb in a loop, thus allowing the
runtime the opportunity to switch context.
That's like saying the earth can start revolving the other way. =)
Sure, that's nice to suggest (and thank you), but suppose I want the
dylib to do a whole task by itself? Splitting it up unnecessarily
gets RB involved in the process, which is exactly why I want the
dylib - to divest out of RB for a particular thing.
This seems like a typical thing - RB handles interface duties, while
a dylib handles things behind the scenes. It seems like a natural
encapsulation - RB handles user feedback, the dylib does things and
reports back to the RB interface on a timely basis.
Coding around technological issues (that should be addressed) is sort
of silly, as a concept.
OK, BTW, I found the solution to the question, although it brings up
another question. I put a App.DoEvents call in the callback function;
now everything seems A OK. (Thank you to Mars.) However, the docs say
that "using DoEvents in a GUI app will likely cause instability."
Will it in this case?
Garth Hjelte
Sampler User
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
