Skip to main content
Community Expert
November 23, 2012
Question

ScriptUI [ JS ]: Working with text in a Palette or a Dialog "edittext" field Mac vs. Win

  • November 23, 2012
  • 1 reply
  • 3725 views

Hello all,

recently I downloaded Peter Kahrels' famous "scriptui-2-0.pdf" and began working on some of his examples. I think Peter is developing mainly on Windows OS, so I think it's worth sharing some observations from "Palettes" and "Dialogs" with an "Textedit" field on a Mac.

I found that in both cases, "palette" and "dialog" kind of Windows objects, there are certain possiblities for working with text inside a "textedit" field on a Mac.

TESTED WITH:

InDesign CS5.5 v7.5.3

InDesign CS5 v7.0.4

InDesign CS4 v6.0.6

Mac OSX 10.6.8

MacBook Pro 5,1 Intel Core 2 Duo

Selecting text:

Tab    selects all text in the "edittext" field.

Alt + Shift + Arrow Right    selects one character right from the insertion point.

Alt + Shift + Arrow Left    selects one character left from the insertion point.

Alt + Shift + Arrow Down    selects all text in one paragraph right from the insertion point.

Alt + Shift + Arrow Up    selects all text in one paragraph left from the insertion point.

Inserting text:

Ctrl + Return    inserts a "new paragraph" (\r) symbol at the insertion point.

Cmd + v    inserts text in the "edittext" field regardless where it was copied or cut from (e.g. an InDesign text frame).

Strange: if you choose to copy/paste from an InDesign text frame to the "edittext" field, a new line character (\n) is added after the inserted text in the "edittext" field.

This will NOT happen, if you:

1. copy/paste text from and to the "edittext" field

2. copy/paste text from Apples TextEdit app to the "edittext" field

3. copy/paste text from Adobe Acrobat Pro to the "edittext" field

4. copy/paste text from your browser to the "edittext" field

Alt + Tab inserts a Tab character at the insertion point.

Deleting text:

Cmd + x    cuts selected text from the "edittext" field.

Ctrl + Cmd + d    deletes  text right from the insertion point.

Ctrl + Cmd + Shift + d    deletes  text right from the insertion point.

Delete    deletes  text left from the insertion point.

Copy text:

Cmd + c    copies selected text from the "edittext" field.

Strange: a part of a paragraph with a end of line character (\n) copied from an InDesign text frame was left out.

I still have to verify that phenomenon…

Moving the cursor:

Ctrl +  Cmd + a    moves the cursor at the beginning of a line.

Ctrl + Cmd + Shift + a    moves the cursor at the beginning of the previous line.

Ctrl + Cmd + e    moves the curser to the end of a line. Sometimes at the end of the previous line.


Differences from "palette" to "dialog":


Esc     closes a "dialog", does nothing on a "palette".

WARNING: Esc also closes a "palette" when a "dialog" is present. It not only closes it, but destroys the "palette".
EDIT: when run in the same #targetengine.

Uwe

Message was edited by: Laubender

This topic has been closed for replies.

1 reply

Peter Kahrel
Community Expert
Community Expert
November 23, 2012

Hi Uwe,

Thanks very much for this report. You're right, I use only Windows (though I'm often tempted). I'm aware that ScriptUI's behaviour varies between OSs, and your report adds interesting things. Here are some responses:

> Tab    selects all text in the "edittext" field.

Didn't know that. Other controls don't respond to Tab like that. This is only in dialogs. In palettes it works if you don't have a document open -- if you do, the tab is sent to the document. Focus problems continue to haunt palettes, even in CS6. Protest, send bug reports.

> Alt + Shift + Arrow Right/Left/Down/Up

In Windows, selection in edittext controls works as expected.

> Ctrl + Return    inserts a "new paragraph" (\r) symbol at the insertion point.

In CS6 a useful creation property was added: wantReturn:

var e = myWindow.add ('edittext', [0,0,300,300], "", {multiline: true, wantReturn: true})

this causes the Enter/Return key to insert a new line in the edittext control. The trouble with Ctrl+Return is that it doesn't work on all laptops.

> Cmd + v    inserts text in the "edittext" field regardless where it was copied or cut from (e.g. an InDesign text frame).

This works in palettes with no document open and in dialogs. Did you try it in a palette with a document open?

>Strange: if you choose to copy/paste from an InDesign text frame to the "edittext" field,

> a new line character (\n) is added after the inserted text in the "edittext" field.

> This will NOT happen, if you:

> 1. copy/paste text from and to the "edittext" field

> 2. copy/paste text from Apples TextEdit app to the "edittext" field

> 3. copy/paste text from Adobe Acrobat Pro to the "edittext" field

> 4. copy/paste text from your browser to the "edittext" field

Doesn't happen in Windows. Right-click and Copy or Paste work without any problem; Ctrl+C or V are problematic in palettes if you have a document open.

> Alt + Tab inserts a Tab character at the insertion point.

Ctrl+Tab in Windows.

> Deleting text:

In Windows you use the familiar keys.

>Delete    deletes  text left from the insertion point.

Right from the insertion point in W.

> Copy text:

> Cmd + c    copies selected text from the "edittext" field.

Ctrl+C does the same in W.

> Strange: a part of a paragraph with a end of line character (\n) copied from an InDesign text frame was left out.

Doesn't appear to happen in W.

>Ctrl +  Cmd + a    moves the cursor at the beginning of a line.

"Home" in W.

> Differences from "palette" to "dialog":

> Esc     closes a "dialog", does nothing on a "palette".

Same on W.

>WARNING: Esc also closes a "palette" when a "dialog" is present. It not only closes it, but destroys the "palette".

Interesting. Doesn't happen on Windows.

The main problem (on Windows anyway, but I think on the Mac as well) is that edittext controls in palettes have problems with focus, which shows in the silly behaviour of Return, Tab and the cope and paste keys.

Thanks again for this useful overview.

Peter

LaubenderCommunity ExpertAuthor
Community Expert
November 24, 2012

@Peter – in case you answered by e-mail, you have to know that I edited my post and added one observation on using the "Esc" key:

Mac OSX 10.6.8 (German) on a MacBook Pro

Esc

Closes a "dialog".
Does not close a "palette".

WARNING!

If both, a "dialog" and a "palette" are present AND both run in the same #targetengine, then and only then, both windows are not only closed, but also destroyed when hitting "Esc".

I tested this with two scripts, one time running the same #targetengine for both, one time running two different ones.

For other points you made:
Yes, I tested with documents open and no documents open. But I will redo testing, because I had no suspicion, that that will make a big difference.

However: another thing bugs me with using "palette" windows. It seems, that on my configuration, a "palette" type of window will become only visible after a fresh restart of inDesign, if you click one time in the area where the "palette" should be or if you double click the script for the "palette" a second time or you switch to another application and go back to InDesign.

Also: I cannot close a "palette" window immediately with the "red" closing button on the upper left side. I need a few tries or switching back and forth to another application.

This affects InDesign CS5 and CS5.5, not CS4.

Maybe I should  try "window" windows instead of "palette" windows…

Of course a "Cancel" button will do. But also this "Cancel" button requires a callback function for closing. That, I think, is due to my German OS, where a simple "Cancel" button without an defined "onClick" event function does simply nothing. Same goes for the "OK" button.

I have to investigate further on that points…
A "dialog" on the other hand will work immedialtely as expected. However, the issues with the simple "Cancel" and "OK" buttons are also present.

Uwe

Peter Kahrel
Community Expert
Community Expert
November 24, 2012

Uwe,

I did see what you added about the Esc key in palettes and dialogs, thanks.

> I cannot close a "palette" window immediately with the "red" closing button on the upper left side.

> I need a few tries or switching back and forth to another application.

That looks like a Mac thing. Pressing the window's Close button in the frame works fine on Windows.

>However: another thing bugs me with using "palette" windows.

Not sure that I follow what you describe here. What do you mean with 'if you click one time in the area where the "palette" should be'?

> But also this "Cancel" button requires a callback

Isn't that expected behaviour? It's in the nature of a palette to remain on your screen until you explicitely close it. Since palettes can be out of focus, they can respond to Esc only if they're in focus. And if you have to bring it into focus you might as well press the window's Cancel button.

> A "dialog" on the other hand will work immedialtely as expected.

> However, the issues with the simple "Cancel" and "OK" buttons are also present.

That's maybe because of your German InDesign and/or OS. OK and Cancel buttons respond to Enter and Esc only when the button's text is "OK" or "Cancel", or if you add the "name" property, specifying 'ok' or 'cancel'. So these two buttons do nothing in a non-English InDesign:

w.add ('button', undefined, 'Alles klar')

w.add ('button', undefined, 'Raus!')

But these two respond to Return and Esc:

w.add ('button', undefined, 'Alles klar', {name: 'ok'})

w.add ('button', undefined, 'Raus!', name: 'cancel'})

Peter