Shoutbox

I am bumping this thread because there is going to be talks surrounding the new scripting engine and I wanted to find out from everyone what they would like to see in Plus! 5 scripting engine.

Pretty much anything in this thread..? (Long as it's possible, of course)

Yeah I figured that but are there any suggestions outside of this thread? For instance Matti and I were discussing the possibility of being able to have controls some how be an object which you can assign a dynamic function to. Just as an example.

Or being able to assign dynamic callback functions to Windows. We haven't worked it out quite yet it was just an idea discussed.

As in .NET programming? Like MyForm.BtnHello = new Button(); or something?

how about much better dynamic window support? like not having to have it as a xml then edit the xml to change the window?

quote:

---

Originally posted by SmokingCookie
As in .NET programming? Like MyForm.BtnHello = new Button(); or something?

---

Perhaps not actually creating controls, but acquiring an object with control-specific methods, properties and ideally events as well.

js code:

---

var MyWnd = MsgPlus.CreateWnd("Interfaces.xml", "MyWnd");
// Acquire control object for a ListViewControl
var LvFiles = MyWnd.GetControl("LvFiles");
// Methods
LvFiles.AddItem("alpha.txt");
LvFiles.AddItem("beta.txt");
// Properties
Debug.Trace("Item count: "+LvFiles.ItemCount); // = 2
// Events
LvFiles.AddEventHandler("Clicked", OnLvFilesEvent_Clicked);
LvFiles.AddEventHandler("SelStateChange", function(ItemIdx, SelectedState) {
    Debug.Trace("Item #"+ItemIdx+" selection state changed to "+SelectedState);
    Debug.Trace("Item data: " + this.GetItemData(ItemIdx) );
});

---

Of course, all of this is nothing more than an early proposal. Here are my thoughts:

• I believe it would be better to pass event callbacks as function objects instead of function names to prevent global scope saturation.
  
• The "this" context inside the event callback could be set to the control object. By doing so, you don't need to pass PlusWnd and ControlId as parameters to the function, you could access everything through the control object itself. If you still need the window or the control ID, the control object could have properties such as Control:arent and Control::ControlId.

I don't say it has to be this way, it's just something which could be considered.

quote:

---

Originally posted by NanaFreak
how about much better dynamic window support? like not having to have it as a xml then edit the xml to change the window?

---

Certainly, I believe that the new scripting environment should provide sufficient window and control support to remove the need of in-runtime XML rewriting. Matty has already informed me that this is high on his wish list. CodeEditControls and MenuButtonControls urgently need an API - they simply cannot be modified through code in Plus! 4. Ideally, methods could be added to natively (without Win32 API) handle DateTimeControls, HotkeyControls, ProgressControls, ScrollBarControls, SliderControls, SpinControls and TreeViewControls.

I think this would indeed be better. But I thinkt the new engine should be backwards compatible.

quote:

---

Originally posted by SmokingCookie
I think this would indeed be better. But I thinkt the new engine should be backwards compatible.

---

As long as they don't remove any methods from the existing objects and keep the current event handlers (global "OnEvent_" functions) working, I don't see how any of this could break backwards compatibility.

Just had another idea: call script functions from the command line.

For example, you could make shortcuts to activate certain functions, or you could apply them to files, like in the SendTo menu, or as a context menu entry.

Maybe if it's called like this:

code:

---

C:\...\MPTools.exe /script <email> "<script name>" <function> <param1> <param2> ... <paramX>

---

You can have a SendTo option to open a file like this...

code:

---

C:\...\MPTools.exe /script <email> "File Reader" OpenFile "%1" sendto

---

So, for a file at C:\Some File.txt, that would then call the function in the script "File Reader":

js code:

---

OpenFile("C:\\Some File.txt", "sendto");

---

Well, I guess you'd need to specify which intance of Messenger is used to run the script function; could be done by typing an email address into the command line I think.