Question about 2520⌶

[PGilbert]

If I do the following in a clear ws it is working fine:

      url←'http://dyalog.com/'
      ⎕USING←'System.Windows.Forms,System.Windows.Forms.dll'
      wb←⎕NEW WebBrowser
      wb.Navigate(⊂url)
      ⎕DL 2 ⍝ Wait a little bit for the page to download
      htmlDoc←wb.Document

htmlDoc contains the dyalog.com page. Now if I do {}2520⌶1 and redo the same code there is a VALUE ERROR for htmlDoc even if we wait for long time. The WebBrowser control does not seem to return any value to htmlDoc. Why is that ? or what is the proper use of that I beam ?

Thanks in advance.

[Dick Bowman]

Was spurred to experiment with this - find the documentation a trifle opaque.

Putting a {}2520⌶1 at the start of my application, it runs OK first time - but after terminating and restarting (for me, typical development behaviour) I get

EXCEPTION: The calling thread cannot access this object because a different thread owns it.

at what seems to me a rather arbitrary place in the code.

Which somewhat smacks of a different symptom to the same underlying issue.

For the nonce I shall refrain, at least until a plain-English explanation forthcomes.

[JohnD|Dyalog]

Hi Pierre, Dick

The reason for the 2520 ibeam is to separate the interpreter's Windows message queue from the GUI application's queue. If both the interpreter and the GUI use the same message queue, then "oddness" can ensue. The most frequent oddness is the interpreter retrieving (and then processing) a message for the GUI when the GUI is not expecting it. For example, the interpreter processes a keypress message for the GUI when the GUI is already in the middle of a keypress callback. This usually (but not always - it depends on the object) manifests in the message "An Exception occurred at a time when Dyalog was unable to save the exception information". The underlying exception contains more relevant information, but the interpreter does not have access to this information when the exception was raised.

The 2520 ibeam configures the interpreter to use a different thread (and thus a different message queue) for .Net code run from APL thread 0 (note that the interpreter already does this for other APL threads). The ibeam should be used before you execute any .NET code on any thread.

This addresses the above issue, but brings with it another set of considerations.

• GUI created in this mode can only be accessed from thread 0. Attempting to access the GUI from other APL threads results in the exception "The calling thread cannot access this object because a different thread owns it."
• The GUI will only process its message queue when you call a (.NET) function that causes it to do so (such as Show, or ShowDialog). When the interpreter is at a 6 space prompt, it is only processing its own message queue - not that of the GUI. This means that:
  
  • Any action in the GUI that requires message handling is stalled until the such a function is called. I suspect that the Navigate function of the webbrowser uses the windows message queue during communication, and so this is stalled. So the Document property gives VALUE ERROR because there is no document (yet)

Dick, if you have an example of your exception that the above does not explain, then please let us have it.

Best Regards
John Daintree.

[PGilbert]

Thanks for the detailed explanation John. This make us appreciate more your 'work behind the scene' to make the interpreter better.

[Dick Bowman]

Thanks also - I shall try to get back to you with an example of my problem.

But it may take a few days - currently trying to make sense of a situation where +/ gives me a DOMAIN ERROR (running on the exact same data it did without problems 10 seconds earlier) while -/ works just fine. But as always, these things are buried deep within running applications and I need to simplify (and I suspect that BOWMAN ERROR may be the more appropriate response).

[MikeHughes]

I don't use the ibeam - I use the standard & to keep my GUI and Interpreter thread 0 separate.
I use a "Hot Key" in my GUI to drop to a callback so its on the same thread if I want to "play" with the objects
I also have two functions in #.WPF which act like []WG and []WS and work using the Dispatcher class so work from any thread.

I can give more details on any of these items if people are interested