July 9, 2016 at 3:46 am #1936
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?Monkey123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566Class InputDialog Extends DialogMethod New(title:String)Super.New(title)_inputField=New TextFieldLocal input:=New DockingViewinput.AddView( New Label( "Input:" ),"left",80,False )input.ContentView=_inputField_docker=New DockingView_docker.AddView( input,"top" )_docker.AddView( New Label( " " ),"top" )MaxSize=New Vec2i( 512,0 )ContentView=_dockerAddAction( "Close" ).Triggered=Lambda()Close()MainWindow.UpdateKeyView()EndOpened=Lambda()_inputField.MakeKeyView()_inputField.SelectAll()EndEndMethod Open(value:String)_inputField.Text=valueSuper.Open()endProperty InputText:String()Return _inputField.TextEndPrivateField _inputField:TextFieldField _docker:DockingViewEndClass _requestersFunction OpenUrl(url:String)EndFunction RequestDir:String( title:String,dir:String )local req:=new InputDialog(title+" - Enter Directory Path")req.Open(dir)Return req.InputTextEndFunction RequestFile:String( title:String,dir:String,Booly:Bool,stringy:String )local req:=new InputDialog(title+" - Enter File Path")req.Open(dir)Return req.InputTextEndendJuly 9, 2016 at 5:26 am #1939
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.July 9, 2016 at 9:10 pm #1956
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:July 9, 2016 at 11:50 pm #1958
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:Monkey1234567891011Method RequestFile:String( title:String,filters:String,save:Bool,path:String="" )Local future:=New Future<String>App.Idle+=Lambda()future.Set( mojo.requesters.RequestFile( title,filters,save,path ) )EndReturn future.Get()End
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.July 10, 2016 at 2:23 am #1961
Awesome, getting RequestFile to call my proxy RequestFile directly sorted it out.
Thanks for the help.
You must be logged in to reply to this topic.