Control of Text Fields

[richmond62]

This is just my attempt to implement virtual FORWARD, BACKWARD and DELETE keys
in a CALCULATOR stack as a response to Roger Guay's posting on the Use-List:
-

-
The three "buttons" (they are really images) down the bottom will, at least, annoy someone.

[richmond62]

Ooooof;

viewtopic.php?f=6&t=27644&start=30

[richmond62]

OK . . . not what was wanted.

So, let us say, for the sake of argument the code in button '5' goes like this:

Code: Select all

on mouseUp
   put "5" after fld "fWORK"
   select after fld "fWORK"
end mouseUp

Obviously that means that the insertion point will end up after 5.

Now my left arrow emulator button should be able to move the insertion point one char to the left
every time it is clicked.
-

-
So, all this has now been sorted out in a far, far simpler way than was done on the Use-List:

Left Arrow Emulator button:

Code: Select all

on mouseUp
   focus fld "fWORK"
   set the itemDelimiter to " "
   put item 4 of the selectedChunk into FRONTCHAR
   if FRONTCHAR is not 1 then
      select char FRONTCHAR to (FRONTCHAR - 1) of fld "fWORK"
   end if
   focus fld "fWORK"
end mouseUp

Right Arrow Emulator button:

Code: Select all

on mouseUp
   put the number of chars in fld "fWORK" into SSUM
   focus fld "fWORK"
   set the itemDelimiter to " "
   put item 2 of the selectedChunk into BACKCHAR
   if BACKCHAR is not SSUM then
      select char (BACKCHAR + 1) to BACKCHAR of fld "fWORK"
   end if
   focus fld "fWORK"
end mouseUp

Delete button:

Code: Select all

on mouseUp
   set the itemDelimiter to " "
   put item 2 of the selectedChunk into Z4
   delete char Z4 of fld "fWORK"
end mouseUp

Actually am grinding my teeth a bit now I have worked that out as feel foolish I went
"the other way" in my earlier attempt.

[RogGuay]

Indeed, works great with this minor correction in the delete button:

delete char Z4-1 of fld "fWORK"

- makes it work like the Delete key on my Mac.

Thanks,
Roger

[richmond62]

I used:

Code: Select all

on mouseUp
   set the itemDelimiter to " "
   put item 2 of the selectedChunk into Z4
   delete char Z4 of fld "fWORK"
end mouseUp

Because I thought you wanted FORWARD DELETE:
-

-
Alex Tweedly wrote this on the Use-list:

your "left-arrow' emulation gets it wrong if there is a chunk selection active.

so, obviously, that needs looking at.

[richmond62]

your "left-arrow' emulation gets it wrong if there is a chunk selection active.

Now, if I have this in the field "fWORK" script:

Code: Select all

on mouseEnter
   focus on fld "gg"
end mouseEnter

where field "gg" is another field somewhere off-screen, that seems
a good idea, BUT if I then perform a mouseClick inwith field "fWORK"
focus returns to field "fWORK", and there seems to be very little I can do
about it.

And this in the field "fWORK" script (is NBG):

Code: Select all

on mouseDown
   focus on fld "gg"
end mouseDown

on mouseUp
   focus on fld "gg"
end mouseUp

Mind you, this might just "do the trick":

Code: Select all

on mouseEnter
   set the lockText of fld "fWORK" to true
end mouseEnter

on mouseLeave
   set the lockText of fld "fWORK" to false
end mouseLeave

[richmond62]

OK, Happy Campers . . .
-

-
So, the number field, field "fWORKS" has a script:

Code: Select all

on mouseEnter
   set the lockText of fld "fWORK" to true
end mouseEnter

on mouseLeave
   set the lockText of fld "fWORK" to false
end mouseLeave

The LEFT ARROW EMULATOR button has this:

Code: Select all

on mouseUp
   focus fld "fWORK"
   set the lockText of fld "fWORK" to false
   set the itemDelimiter to " "
   put item 4 of the selectedChunk into FRONTCHAR
   if FRONTCHAR is not 1 then
      select char FRONTCHAR to (FRONTCHAR - 1) of fld "fWORK"
   end if
   focus fld "fWORK"
   set the lockText of fld "fWORK" to true
end mouseUp

The RIGHT ARROW EMULATOR button has something similar.

And so do the FORWARD DELETE and the DELETE buttons.

A bit like the one time I tried Vodka: everything kept going in and out of focus.

[richmond62]

Don't you mean "my cooperating version ..."; surely the use-list is about helpful cooperatin and collaborative suggestions, not about competing

1. Some "real prickly types" round these parts.

2. I replied "I did not mean "competing" in the sense of "b*gger you", I meant it in the sense of healthy competition."

2.1. Why on earth I felt it necessary to explain that, when it should have been as obvious as the nose on my face,
escapes me.

3. This "competition" surely shows one of LiveCode's greatest strengths: that there are almost always
more than 1 way to get something done, and . . .

4. Having "competing" ways of solving a problem should be seen as a healthy sign of a LIVE and VIBRANT user community.

5. My version is NOT "cooperating" in the sense that it shares no code with anyone else's attempt to solve
this problem, and in that sense it is "competing".

6. Having explained ALL THAT, any one who wants to "beg, borrow or steal" my code is more than welcome.

[alextweedly]

As discussed in more detail on the use-list, there are a number of flaws with this approach to emulating the arrow/del/f-del keys, to the point that this is basically unusable.

I've changed the scripts for those keys in this modified version. (Can't quite figure out Richmond's naming scheme - so I called his one calc_q)

It uses a simpler approach using the selectedchunk to determine what needs to be done, and fully (AFAICT) emulates regular arrow/del/f-del keys (except for clicking on a digit key when there is an active text selection - that doesn't work in the original version, and I haven't fixed it). Doing so is easy (take the code from my earlier posting to the use-list for 'digit' buttons), but it's tedious to implement in this stack because there is a separate handler for each digit button).

[richmond62]

My "naming scheme" makes things sound a lot more logical that they are:

I started at X, hopped to Z, and then, for some reason that escapes me at the moment went to Q
followed by P . . . naming, Yes, scheme, No.

I am going to post Alex's "crits" here, one by one, as they are undoubtedly valuable,

AND retrench to my last version, which I shall call 'Calc_RM1' in a wild attempt to adopt some semi-sensible
naming scheme, and try to "do things" so that Alex's points are covered, mainly as I find wading through my
own 'dung' attempting to do something a better way to learn things than by looking at other people's code.

This morning, over breakfast, I have already had some 'hairy' ideas relating to the number buttons: we shall see.

[richmond62]

1. the whole 'locktext' thing is weird, and causes various anomalies.
When I first open the stack, and click in the field, I can type digits and have them appear in the field, as you'd expect. But once I've clicked on an 'arrow-emulator' the field becomes locked and one can no longer type in characters. Clicking *outside* the field will then free it up again, so typing becomes possible.

Yes, the "whole 'locktext' thing is weird' . . .

. . . BUT with a bit of tweaking may not seem so weird . . .

2. disappearing iBeam.

If I position the ibeam in the middle of the text in the field, and use one of the arrow emulator buttons, the iBeam moves properly - but then disappears (perhaps when the 'locktext' is set true).

That is a pain-in-the-bum as, yes, the insertion point ('iBeam') does disappear when the lockText is true,
presumably because in LiveCode centre the logic behind that is that an iBeam shows the end-user that s/he can
access that field and modify it . . .

[richmond62]

So . . . here we go . . .

Modifying the NUMBER buttons like this:

Code: Select all

on mouseUp
   set the lockText of fld "fWORK" to false
   set the itemDelimiter to " "
   put item 2 of the selectedChunk into Z4
   put "0" after char (Z4 - 1) of fld "fWORK"
   set the lockText of fld "fWORK" to true
end mouseUp

This means a number is inserted at the iBeam (whether visible or not )
rather than always at the end of the row.

And have put this in the cardScript so the end-user cannot start mucking around
with number or letter keys on their keyboard in the field:

Code: Select all

on openCard
   set the lockText of fld "fWORK" to true
   select after fld "fWORK"
end openCard

[richmond62]

Clicking *outside* the field will then free it up again, so typing becomes possible.

This is odd; over 'here' on a Macintosh machine (macOS 12.1)

clicking outwith the textField BUT inwith the stack does NOT unlock the field,

BUT clicking outwith the stack (say, on the desktop) DOES unlock the field.

Why does this strike me as anomolous?

Probably because if I click outside a LibreOffice document, a GIMP document or a TextEdit document

(the 3 apps I use most often apart from LiveCode)

that click does NOT affect those documents at all.

[richmond62]

Mods as mentioned above.
-

[RogGuay]

With continual help from Alex and Richmond, I offer my Formulator stack which I have also uploaded to Sample Stacks:
This is an emulation of the one used in Mac Good Grapher but customized for LiveCode. You should also recognize that it is a work in progress and all feedback is welcome.

Formulator.livecode.zip

(4.91 KiB) Downloaded 153 times