Mojox question

This topic contains 4 replies, has 2 voices, and was last updated by  Simon Armstrong 2 years, 11 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #1936

    Simon Armstrong
    Participant

    I am trying to add a basic RequestString method to Ted that waits for user input and returns the string entered. For test purposes I am trying to use it to replace standard file requester behaviour.

    Mark, is there a way I can hook this up so my mojox dialog behaves like a native requester?

    #1939

    Mark Sibly
    Keymaster

    Check out the TextDialog.Run() function for an example of a modal dialog.

    The key thing is that Run() MUST be called on a fiber because it blocks. The bit that actually blocks is the “Local r:=result.Get()” line.

    #1956

    Simon Armstrong
    Participant

    I feel lazy for asking but I just wanted to check, in the following I am pressing Ctrl-O to open file which causes I thought the Run code to happen in a fiber.

    I think I am getting confused thinking anything in Lambda form is in it’s own fiber.

    Attachments:
    #1958

    Mark Sibly
    Keymaster

    I can’t see where you’re actually calling ‘RequestDir’ so it’s hard to say what’s wrong.

    But there is an issue to do with the native mojo.requesters functions you may be encountering. These have to be run on the GUI thread on some targets (macos I think…) so due to the way the fiber system used to work (ie: fibers were really threads) I had to wrap them like this if I wanted to be able to call them from a fiber:

    What this does is ‘switch back’ to main thread (App.Idle callbacks always run on the main thread) to run the native requester, and then switch back to the original fiber after the requester completes. Note that this was a special case fix that was only necessary due to limitations of system requesters (and the old fiber system). With the new fiber system, this wrapper should no longer be necessary as fibers are no longer threads (so you can now safely render on fibers too!).

    So if you’ve placed your StringDialog.Run call inside an App.Idle+=Lambda somewhere, you’ll actually be running the dialog on the main thread – possibly the complete opposite of what you were thinking! If you’ve done this, the fix is simply to call StringDialog.Run() directly instead of inside App.Idle. To start with, try calling it at the top of OnFileNew() or OnFileOpen() or something for testing.

    Ted2 fiber creation is actually handled by the ‘Action’ system. By default, when you Trigger() an action (which is what clicking a button or selecting a menu item etc do) a new fiber will be created to run the ‘Triggered’ callbacks (see Action.Trigger() source). Since all menus, buttons and hotkeys are implemented via actions, the action code is always called on a fiber and can therefore safely ‘suspend’ itself whenever it wants.

    Actually, once Ted2 is up and running, the only code that runs on the main fiber is the OnBlahEvent handlers in mojox. These typically result in an action being triggered somewhere so all/most of the code in MainWindow ends up running on a fiber. Actually, it occurs to me this is not true in some case, eg: TabView.TabChanged doesn’t start a fiber I think, and probably should.

    #1961

    Simon Armstrong
    Participant

    Awesome, getting RequestFile to call my proxy RequestFile directly sorted it out.

    Thanks for the help.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.