Toggling Browse and Edit tool issue

[WaltBrown]

I built a stack (

id80CharDisplay.zip

(1.06 KiB) Downloaded 217 times

) to try to emulate an old 80 character display (from reading this issue http://forums.livecode.com/viewtopic.php?f=9&t=24107).

The issue is the flashing cursor. When the stack is opened and you click on the line you get the flashing square insertion point. But if you toggle to the Edit tool and back to the Browse tool, the cursor flashes rather than toggles. It can be corrected while in the Browse tool by clicking on some other stack then back.

So the questions are:
Why does the switch of tools break the insertion point field script?
What message does a stack get when you switch between the Browse and Edit tools of the IDE?

Any thoughts? Thanks.

[WaltBrown]

Anyone have any thoughts on this? Should I repost it to the Bug Discussion? Thanks.

[dunbarx]

Walt.

A lot of messages.If you do not suppress IDE messages, you will see all the usual suspects when doing stuff in the tools palette. If you do suppress them, then what we normally think of as normal messages do not get sent from that palette, as well as what we (I)? normally think of as the more esoteric IDE messages. I assume that these are set aside because of where they derive from?

MouseUp and mouseDown, newTool, and many others. Some of these may wreak havoc with the insertion point, which is a fragile thing, actually.

Craig

[FourthWorld]

There's "with the grain" and "against the grain", things that work easily within a given context and things that work at cross purposes to that context.

If your terminal emulator were a standalone, IDE messages would never come into play and it would be much simpler to design and build.

If it it's designed to be used within the IDE, the IDE is obliged to support common UI conventions wherever practical, and a flashing I-beam cursor is far more common (almost exclusively) in GUIs than a block cursor.

So if the tool is designed to eventually be a standalone, don't worry too much about the IDE and just make sure it works in the final standalone form you want to deliver it in.

And if the tool is designed to be an IDE plugin, if you let go of that one element, the block cursor, and adopt the more conventional I-beam instead, your path to a useful tool becomes much simpler.

[WaltBrown]

Thanks Richard. This was just an experiment based on the earlier thread - I was trying to emulate an 80 char display for, eventually, all keyboard actions, as an exercise, not fpr a product. Hmm, maybe vi, DCL, or Gold Key in Livecode.....

[FourthWorld]

While there's no support for vim in the engine, check out the emacsKeyBindings property in the dictionary. It'll be difficult to get it to work well in the IDE (since the IDE's keyboard shortcuts will conflict), and I'm not even sure if it still works with all the deep field changes introduced since v5.5, but if it does work your emacs users will love you for using it.