edit a field while another object is selected

[raugert]

I am working in "pointer mode" during runtime to allow editing of objects, but I would like to edit the text in a "field" while keeping the other object selected.

I set the field to "cantSelect" so that the other object remains selected. Now when I click in the field, the cursor is visible in the field but I can't add any text to it..

thanks for the usual help.

[FourthWorld]

Reproduced here. Not sure if it's a bug per se, but there's an argument that it should be considered a bug given that the goal of cantSelect is to allow an object to behave as though the browse tool is selected, and the browse tool is the only one which allows text entry.

You might consider submitting a bug report on that. Given that this behavior has been in place since cantSelect was first implemented the team may recategorize it as an enhancement request. Either way, unless this is something that's especially easy to remedy, I wouldn't expect an engine change for this any time soon (very rarely needed, and v9 just went into RC so the earliest this could be considered would be weeks away in the v10 cycle).

I can think of two workarounds:

a) Move the field to a borderless palette window, dynamically positioned when the stack beneath it moves.

b) Dynamically change the global tool property from pointer to browse when the mouse enters the field. To preserve the selection you can do something like:

Code: Select all

on mouseEnter
   lock screen
   put the selectedObjects into tSelObjs
   choose browse tool
   repeat for each line tObj in tSelObjs
      set the selected of tObj to true
   end repeat
end mouseEnter

[bogs]

Erm, 3rd choice, use the message box to change the contents

[FourthWorld]

Erm, 3rd choice, use the message box to change the contents

Difficult in a runtime environment without a Message Box, but indeed some external means of editing field contents, such as we see in spreadsheets, may not be bad.

Still nice to directly interact, though. Users love the direct interaction of see-and-click, without having to think about other regions of the screen than the one they want to change.

[raugert]

Thanks very much Richard,

I was thinking it should behave like that as well. I'll submit a bug/request report. Your workaround (b) works good for what I'm doing.

much appreciated!

[bogs]

Still nice to directly interact, though. Users love the direct interaction of see-and-click, without having to think about other regions of the screen than the one they want to change.

True that.