[Solved] Get Set Modify the script name for dialog control events

[Alex6361]

Using Basic, how does one get, set, remove or modify which macro script gets run for each event of a control on a dialog?

[JeJe]

You have to write the macro first in a module then double click on the dialog control in the IDE
Choose the events tab of the properties window that pops up. Click on the ... at the for right for the event you want to set
Click on the macro button in the assign action window to look up the macro you already wrote for it.

[Alex6361]

My question is not how to do these things using the IDE Dialog editor, but how to do them from within a Basic macro. I can get which events a control will respond to, but not which macro script will be run if that event is triggered. How does one get access to that programmatically?

[JeJe]

Do you want to assign a macro at runtime?

viewtopic.php?t=25499

If you want to take control of the IDE dialog page using basic - I think the best you could do would be to export the dialog, edit the xml file, then import the edited version.

[JPL]

To assign a macro at run-time:

Code: Select all

Sub RunDialog()
	GlobalScope.BasicLibraries.loadLibrary("ScriptForge")
	oDlg = CreateScriptService("dialog", "yourfilehere.odt", "Standard", "Dialog1")
	oBtn = oDlg.Controls("myButton")
	oBtn.onActionPerformed = "vnd.sun.star.script:Standard.Module2.Message?language=Basic&location=document"
	oDlg.Execute()
End Sub

Sub Message(Optional Event)
	MsgBox "Button fired !"
End Sub

Notes:

• Assigning the empty string to oBtn.OnActionPerformed erases the macro assignment.

• oBtn.OnActionPerformed returns a string containing the actual assignment.

• The macro assignment can be done at any moment during the dialog's lifetime, including in event subs.

• Any event-type associated with a dialog or one of its controls may be assigned dynamically to a macro the same way.

Documentation on LibreOffice help.

[Alex6361]

My thanks to JeJe and JPL for their responses. You did not actually answer the question I posed, but provided alternate ways to essentially achieve the end goal. I suspect that might be because direct programmatical access to those properties from Basic is either not possible or is so arcane, messy or complicated that no rational person would try to do it, and would instead look for another way.

JPL's solution involves the use of the Script Forge libraries, and requires that dialogs be invoked by means of those macros instead of the CreateUnoDialog service. The documentation for the Script Forge SFDialogs.DialogControl service has the warning: "Assigning events via the Basic IDE and assigning events via macros are mutually exclusive." It's as if the kind of Control model Script Forge creates is different from that which CreateUnoDialog creates, and uses different syntax in the statements -- like myDialog.getControl(<controlName>) vs. myDialog.Controls(<controlName>). That works, but one has to then do all one's access and manipulation of the control with the Script Force functions.

Because I had already started with the CreateUnoDialog approach and have many statements already scattered through various modules using its syntax, I ended up with the approach of not trying to modify the OnActions in the control initially set by means of the IDE Dialog editor, but making the script which gets called from those actions do different things according to the context in which the Dialog is being used in each invocation. I'm satisfied with that solution, and might have done that to start with, except I'm trying to convert Excel VBA to CALC Basic, and it was so easy to set and modify the OnActions 30 years ago with Excel that I just blindly proceeded with the same approach before discovering that CALC has a completely different and obscure way of doing this.

[Bidouille]

You did not actually answer the question I posed

Provide a document to show us what you want. It will save us time.

[Alex6361]

I would have marked this as SOLVED except I couldn't find out how to do that. JPL gave a valid solution that works. But the question I was trying to ask was how does one do that using StarBasic directly, because I was unable to discover on my own how to access those methods/properties. Though I had seen that there were Script Forge functions to access various aspects of spreadsheets, it was not obvious to me that they were any different or better than just using what I'll call direct access as described, for example, in Andrew Pitonyak's very comprehensive and invaluable resource "OpenOffice.org Macros Explained". I just assumed that they only offered what some would consider easier or more intuitive ways to do things. What I learned from JPL was that dialogs created with the Script Forge methods reveal different methods and properties for those dialogs and their control elements than those created directly with StarBasic. It would seem that the folks at Script Forge recognized some limitations with the CreateUnoDialog service and came up with a different service (SFDialogs.DialogControl) to overcome some of those limitations. That's nice to know for the future, but it suggests to me that if one wants or needs those Script Forge advantages, one has to use Script Forge macros exclusively, and not mix them with more direct access methods. I welcome clarification on that assumption.

[JPL]

it suggests to me that if one wants or needs those Script Forge advantages, one has to use Script Forge macros exclusively, and not mix them with more direct access methods. I welcome clarification on that assumption.

The short answer:
- with ScriptForge, people who don't know UNO can make nice scripts without having to learn it in a first step.
- people who know UNO may make scripts that mix the ScriptForge and UNO API's. This is facilitated by all the X... properties proposed by the SF API (examples: XDialogModel, XDialogView, XControlModel, XControlView).
- as an exception (for technical reasons only), dialogs and their controls must be started with ScriptForge if and only if the user wants to use ScriptForge methods afterwards and/or in events handling. To set dynamically OnAction... properties, then, yes, start the dialog with ScriptForge because, apparently and shown in this discussion, nobody knows how to do it otherwise.

The long answer:
- (video) Is ScriptForge really a scam? - LibreOffice Conference 2022
- (slides) Is ScriptForge really a scam? - LibreOffice Conference 2022

[Alex6361]

JPL, thanks so much for taking the time to help me understand what ScriptForge is and can do! Your short answer addresses my questions succinctly, and your long answer provides useful underlying context. I am exactly the type of user you describe in the opening of your video: a spreadsheet user who finds it helpful to create dialogs and supporting code to get data into and out of spreadsheets in a controlled and coordinated manner. I can code in several languages, yet don't consider myself a programmer but a problem solver who uses programming when it can solve a problem. As you mention in the video, Microsoft recognized the existence of people like me from the beginning, but the developers of Open/LibreOffice have not shown evidence of that, and it's a tough slog to do with LibreOffice what I've done for so many years with Excel. Thanks to you and to people like you who recognize that deficiency and are trying to do something about it!