deriving character (count) from mouseChar?

Need help with a script? This is the place to discuss how to get your code running!

deriving character (count) from mouseChar?

Postby Randall Lee Reetz » Tue Apr 12, 2016 12:29 pm

I need to track the exact character count (example: char 342 of cd fld 1) of the character in a text field that is directly under the mouse.

Currently, I have accomplished this within an idle handler by selecting the mouseChunk and then calling the selectedLoc (screen position of top left corner of text selection) and then using the stringWidth function in a repeat loop iterating on each char of the mouseText that matches the mouseChar until the mouseH is within width of the current test string vs the test string minus on char. Whew!

The problem is that this routine requires all kinds of selecting and unselecting of text in an open field, and requires some tricky locking and unlocking of the screen and tracking and adjusting for scroll etc. to avoid maddening visual flashing (not to mention the purposeful muting of all of the focus effects and problems with the disruption of user text selection.

If I could simply enquire of the char count and the onscreen loc or the rectangle of char under the mouse (the mouseChar), this whole rube goldberg process could be circumvented.

Anyone know of a way to derive the bounding box and char count of the character currently under the mouse without disrupting the current display of the field?

If not, if there is not a simple way to do this, I might try a slightly less awkward hack involving constant idle clicking of the mouse (click at the mouseLoc) and comparing the selectedChunk function expression to determine the char count of the character count of the character under the mouse. But again, such a method causes a disruption in the display and editing functions baked into macintosh text fields… both slow and disruptive. Oops, tried this, not good. Doing so causes double click messages up the wazoo and corresponding automatic text field behavior such as the selection of the word or group or whole paragraph being double clicked and triple clicked. I tried quieting the double click reactions by setting the allowDoubleClick to false but to no avail.

I tried yet another route, I tried setting the wordDel to "" or empty thinking that doing so might treat individual characters as words, and thus circumventing the above mess and replacing it with one simple call: select the mouseChunk. But Supercard expects the wordDel to be a character and won't accept empty as an argument.

There seems to be two conflicting issues here. The conflict results in a clash between querying text information on the one hand and the text editing gestures that are required for selection. Text fields are generally used for standard text sequencing (typing), editing (select, copy, past, and formatting), and reading of prewritten and pre-edited and formatted text. I am experimenting with other methods of presenting, navigating, and composing text. I want to variously circumvent normal macintosh text field behaviors and implement others to see if they offer advantages. I am building up a library of semantic chunk extraction and manipulation routines and playing with text creation and browsing affordances that exploit encoded meaning in text. In my experiments, text isn't just a series of chars delimitated into hierarchical syntactical chunks (chars, phonemes/syllables, words, parts of speech/phrases, sentences, paragraphs, sections, chapters, volumes, sets, libraries, etc), but linked meanings and associations.

I want to selectively activate or deactivate the various automatic text field behaviors and add in my own and do all of this on the fly depending on the user's goals and individual methods of achieving those goals, and or their current place in their own work-flow routine.

Simply speaking, I want a text environment to act differently and appropriately when one is editing a part of text that abstracts a person, than it acts when one is editing a part of text that abstracts an action, etc.

To do this, I need to allow the user to select text by semantic chunks (which may or may not correlate to the standard syntactical chunks (chars and words) offered up by the standard macintosh text field behavior suite.

At minium, I need to know the bounding pixel region of the current chunk, as well as its corresponding chunk expression. I need to be able to provide a geographic rect and extract a chunk expression, and I need to provide a chunk expression and derive a chunk expression. It would be grand if I could ask of and set the chunk size (char, word, phrase, sentence, etc.) that the mouse text function is using to determine what to return regarding the text under the current mouse loc.

Three suggested changes to the SuperTalk function set:

1. Allow the wordDel to accept a null argument (no delimiter), so that the mouseText and mouseChunk functions would return data that corresponds to user-defined chunking (from zero delimiter chars to standard space char separated words to other arbitrary user defined chunks). Note: There are various field and text functions and commands that work via text chunking delimiters (char, word, and line) that DO NOT respond to user defined text chunking delimiter settings (example: mouseText, mouseChunk, etc.). It would be really helpful if ALL supercard functionality was keyed to user delimiter setting. I realize that some internal run time code might have to respond to its own delimiter presents, but that should be true anyway and should be protected from user logic and user perimeter settings.

2. Return two line separated items when the mouseChar, and mouseText functions are called — the character or "word" under the mouse in the first line, and the chunk expression of that char or "word" in the second line)

3. A function that returns the pixel geographic description of any string of text in any text display container. Compare to the existing textLoc function but returning both TopLeft and BottomRight local pixel coordinates.

Note: importantly all such functionality should work from chunk expressions OR from topLeft, bottomRight pixel coordinates and conversion functions should be offered from both to the other.

If such functionality currently exists, please forgive my ignorance and point me towards it.

Thank you much,

Randall Lee Reetz
What matters is what matters, knowing what matters and how to know it, matters the most.
Randall Lee Reetz
Posts: 64
Joined: Fri Mar 07, 2014 3:29 pm

Return to Scripting in SuperTalk

Who is online

Users browsing this forum: No registered users and 2 guests