Framescript Medit dialog with checkboxes - restrict selection to one

[rombanks]

Hello framers!

I don't see a way to restrict checkbox selection in the Medit dialog box to only one out of X. Is this possible?

Many thanks!

Roman

[4everJang]

You need a radio button for that.

[rombanks]

Hi Jang,

I appreciate your response!

Medit doesn't seem to support the radio button option.

Regards,

Roman

[4everJang]

Hi Roman,

Can you show the code you have? I don't know Medit yet. Is that part of the ScriptUI library?

I have always used the Dialog anf built my own controls, rather than using the layout manager. In cases where a radio button was not possible or not desirable but I still wanted a similar effect, I added some code on each of the check boxes that unchecked all the other boxes. A bit of code might help in offering better help.

Good luck

Jang

[rombanks]

Hi Jang,

Thanks for your response!

I think you have Extendscript in mind while I am writing a Framescript.

Here is the relevant piece of code:

Set vEdit1 = '';

Set vCheckBox1 = 0;

Set vCheckBox2 = 0;

DialogBox Type(Medit) Title('Sample Dialog')

Label1('Enter the URL:') Edit1(vEdit1)

CheckBox1Label('A') CheckBox1(vCheckBox1)

CheckBox2Label('B') CheckBox2(vCheckBox2)

Button(vButton);

IF vButton = CancelButton

    LeaveSub;

ENDIF

...

The dialog allows selecting both of the checkboxes. I'd like to make them mutually exclusive. But I don't see a way to do that in this context. The problem is that before clicking OK, there is no way to check if both checkboxes are selected.

Thanks,

Roman

[4everJang]

OK, yes, FrameScript instead of ExtendScript explains the confusion. I have stopped using FrameScript after ExtendScript was brought to FrameMaker in version 10. The main reason at the time was not forcing my customers to download and install a third party product. Not because it was not worth the money, but my customers were lone writers in a large organisation and could not install anything, as their computer - and especiallly the Program Folder - was owned by IT, who would not allow any external stuff in there.

After moving to ExtendScript I found it to be immensely more powerful than FrameScript, as it taps into JavaScript methods and objects, which means you get the same types of events and callbacks that you would have in a web browser (or a subset of them, anyway). That makes scripting life a lot easier and the scripts much more powerful.

I don't know if FrameScript has something like events in the dialogs. I am sure Rick Quatro can answer this, as he has been working in FrameScript a lot longer than I have.

Good luck

[rombanks]

Hi Jang,

Yes, you are right. I would prefer to use ES but the problem is that it is not as user-friendly as Framescript and it is not documented properly. For an inexperienced user, who creates scripts sporadically, it is much easier to use Framescript as it is at least documented properly. For many years, Adobe promised to provide better ES documentation but so far no detailed guide is available. Not everyone has time to play with ES and learn it based on trial and error only.

Regards,

Roman

[rombanks]

Hi Jang,

Have you ever checked if it is possible to bind an extendscript to a custom button on a custom FM toolbar? This is quite easy to do with Framescript but not sure if this can be done with extendscript  as well. AFAIK, extendscripts can only be hooked into a menu/dialog but not to a button on a toolbar, but maybe I am wrong.

Thanks,

Roman

[4everJang]

I have completely replaced FM's toolbars with customized ones, using my own icons and extenscripts that are fired by these buttons. This is what my customer sees when they open an XML document.

Only the first 4 buttons in the Quick Access bar and the first 4 in the Tables toolbar are originally there. The icons with the letters do not do anything - they are inserted to give the author a cue as to which elements are being handled by each toolbar. Separate toolbars are driven via separate ExtendScript libraries, which can be made to load depending on the user's login name (via an XML configuration file). Updating a single library, or even a single function from a library, can be done without recompiling or even reloading anything else. Libraries can be unloaded without restarting FrameMaker. Most of this is possible due to specific characterisrtics of JavaScript, which is the base of ExtendScript.

Short answer: yes, I have.  🙂

[rombanks]

Hi Jang,

Sounds good!

Not sure why you had to replace the original toolbars, but I guess you had a good reason for that.

Creating a dialog with buttons is shortly described in the Javascript Tools guide. Are you aware of any additional resource that describes the dialog/image-based button creation in a more detail?

Best Regards,

Roman

[4everJang]

Hi Roman,

The toolbars needed to go because this application does not allow any editing, just formatting in FrameMaker. The buttons do lots of stuff under the hood, make sure they cannot make stupid mistakes and also make sure that everything is correctly entered into the XML. Very specific application and the most elaborate customising of FrameMaker I have done until now.

About help on dialogs beyond the Javascript Tools guide - no, I don't think there any any other resources specifically for ExtendScript. As I mentioned in another thread, I am planning to write a full tutorial on creating HTML Dialogs but that will not be available for at least a couple of months. If you have FrameMaker 2019 and installed update 2 (check the FM version number, it should start with 15.0.2), you can see such an HTML Dialog in the Structure > DITA > Customise DITA plugin.

Kind regards

Jang

[rombanks]

Hi Jang,

I appreciate your response!

Not sure why you mentioned HTML dialogs. The FM pods don't look like anything related to HTML. What am I missing?

Regarding FM19 - I have no plans to upgrade as the trial version of FM19 really disappointed me (probably, my expectations were too high). Even if I wanted to give it a second chance, I can't as the trial had expired. I am staying with FM13 - the most stable FM version I had so far.

[4everJang]

No, the older versions had Pods with no HTML whatsoever. They were introduced in FM2019 (although the HTML based welcome screen was there earlier). With HTML dialogs, a lot of UI techniques become available that are simply impossible in ExtendScript dialogs. It is not the easiest in coding but very powerful.

Sorry to hear you were disappointed with the FM2019 release. A lot of effort for that release went into upgrading all the code to 64 bit and using the latest libraries of included components. It was a major overhaul and may have left some with the impression that not much was done. I have been creating tons of heavy-duty scripts in FM since verison 10 and have seen so many crashes, as I was always pushing FM to the limits of what it can do. I am seeing an immense drop in crashes with FM 2019 even though I am doing far more dangerous stuff than I ever have before.

Not everyone may need this, but if you do want to get some serious automation going there is really no reason to stay with older versions of FM believing that they are more stable. FM 2019 64 bit is more stable than any version I have seen before. This may not be true for the first release but it is certainly the case with the latest update.

Kind regards

[rombanks]

I now see what you meant. Thank you for the information, Jang!!

HTML-based dialogs definitely offer more flexibility.

Looking forward to seeing your blog! I am sure it will be the best ES resource ever created.

My Best Regards,

Roman

[Ian Proudfoot]

There is a very good ScriptUI reference by Peter Kahrel. It goes into far more depth than the original Adobe document. There's a link to the PDF file on this page: ScriptUI for dummies | Peter Kahrel .

Regards

Ian

[rombanks]

Great. Thank you for the pointer, Ian!

Best Regards,

Roman