How to revert to the previous hilite in a list field?

[sritcp]

I have a scrolling list field that lists some names.
Clicking on one of them shows data fields associated with that name.
When the user has made some edits to that data and then tries to move on to another name by clicking in the scrolling list field, the program should alert him to either save the edits or cancel before moving on -- and then return him to the previous state (i.e., restore the previous hilite in the list field).
Saving the current hilitedLine in a global variable is a cumbersome way to do this.

I feel there must be a simpler way. Is there?

Thank you,
Sri.

[dunbarx]

Hi.

The current hilited line is a property of the field. The previous one is nowhere to be found, so it has to be explicitly remembered somewhere.

How about a custom property of the field itself? More direct than a global, which most people like to use as little as possible. Set such a property each time a line is selected, and call for it as needed. You can queue these for a bit if you want to, and get earlier versions, if this seems useful.

Can you implement this? Write back if you need help.

Craig Newman

[sritcp]

Hi Craig:

Yes, I see that a custom property is more appropriate than a global variable here.
I can do this, of course.
I was simply wondering why there wasn't a built-in solution since there is need to cancel user's menu pick and revert to the previous state.

Thanks,
Sri.

[dunbarx]

I see what you want now.

So when the user returns to the list field and clicks another line, the old selectedLine, still hilited, changes, but only if you have confirmed valid data. There are likely a million ways to do this. Maybe this will give you a start.

I made two fields, a list field named "yourList" and an editable field "editData"

in the script of fld "yourList":

Code: Select all

on mouseup
   set the currentLine of fld "yourList" to the hilitedLIne of fld "yourList"
   show fld "editData"
end mouseup

and in fld "editData":

Code: Select all

on closeField
   put word 2 of the mouseLine into newLine
   answer "confirm data? " with "OK" or "Cancel"
   if it = "Cancel" then
     select line (the currentLIne of fld "yourList") of fld "yourList" 
   else
     select line newLine of fld "yourList"
   end if
   hide fld "editData"
end closeField

When you click on a line in "yourList" the line is hilited, and the fleld "editData" comes up. If something is changed there, when you click back on field "yourList", you are asked to confirm the data. If you say "OK", the new line you clicked on hilites, and "editData" disappears. If you say "Cancel", the original line stays hilited, and you can do something else. You will have to handle things like that, multiple edit fields, the fact that since I used "closeField" the editField data has to change to make this work (look up "exitField" in the dictionary), and likely lots of other stuff.

Anyway, I played around with the idea that the actions of one field interact with the actions of another. This is a kluge, but your problem may require such a thing. Write back with your progress. I am keen to see how it goes.

Craig Newman

[sritcp]

Hi Craig:

Thanks for the suggestion.
1.
a. I see a possible problem with placing the 'save alert" in the closeField message (as you have done). closeField is sent whenever the user clicks anywhere outside the entry field, not necessarily in the list field. So, if the user clicks somewhere outside a given edit field (or goes to the next edit field, if there are several), the mouseLine function will not return the expected result (will return "empty").
b. On a different matter, the dictionary recommends using "set the hilitedLine" property in preference to "select" command in case of list fields. I am wondering if "select" command will send a "mouseUp" message to the list field. If it does, it will reload the edit fields with old data, resulting in the loss of any unsaved edits.

2. I am wondering if a front script that captures the mouse click in the list field would work. If there are unsaved edits (as flagged by a variable or a property of the edit fields group), it blocks the mouseClick. Otherwise, it passes the message. What do you think?

Regards,
Sri.

[Klaus]

HI Sri,

why don't you simply supply an "Edit" button, which will disable the listfield
and a click on "Cancel" or "OK" will enable it again?
Know what I mean?

I don't think that a listfield that you can click but might revert to previous hilite out of a sudden
and will alert you or whatever is a good user experience!


Best

Klaus

[dunbarx]

Did I mention this was a kluge?

You can certainly do what Klaus mentioned, which disconnects the actions of the two fields, but adds another element to the process. You should try to make the clean field-to-field process work the way you intended. I like that.

So instead of testing to see if the mouseLoc is within the rect of the listField, or something even more klugy, why not try this script in the listField:

Code: Select all

on mouseup
   if not the visible of fld "editData" then
         set the currentLine of fld "yourList" to the hilitedLIne of fld "yourList"
         show fld "editData"
   else
      put word 2 of the mouseLine into newLine
         answer "confirm data for" && the line (the currentLIne of fld "yourList") of fld "yourList"  && "? " with "OK" or "Cancel"
         if it = "Cancel" then
              select line (the currentLIne of fld "yourList") of fld "yourList" 
         else
              select line newLine of fld "yourList"
            hide fld "editData"
         end if
   end if
end mouseup

Empty all scripts in the edit field. What do you think?

Craig Newman

[sturgis]

Something like this (could be cleaned up and simplified most likely) might be an answer.

Code: Select all

on selectionchanged
   if (the oldSelect of me) is empty then set the oldSelect of me to the hilitedlines of me
   switch
      case (the oldSelect of me) is (the hilitedlines of me)
         break
      case (the oldSelect of me) is not (the hilitedlines of me)
         if the changedFlag of me then -- this flag would be set when a change occurs elsewhere
            answer "Are you sure you want to switch records without saving?" with "YES" and "NO"
            if it is "YES" then
               set the oldSelect of me to the hilitedlines of me
               set the changedFlag of me to false 
               -- would call the handler to grab the new info here, and reset the changed flag
            else
               set the hilitedlines of me to the oldSelect of me
               -- reverts to previous selection
            end if
         else
            set the oldSelect of me to the hilitedlines of me
            -- executes if your changed flag (or however you track that)
            -- was not true. 
            -- would call the handler to grab new info here.
         end if
         break
   end switch
end selectionchanged

[sritcp]

I see four different ways of dealing with this issue (I am sure there are more).

A little more detail might help.
The card has a scrolling list field containing the names of students: Jack, Jill, John, Mary, ...
There are several data fields containing student-related information: date of birth, contact persons, some technical data, etc.
There are also several buttons on the card: Add New, Edit, Save, Cancel, Delete, Done, etc.

1. Use of a custom property to hold the previous selection (as suggested by Craig and sturgis) seems to be the most straightforward approach. sturgis, yes, I do use a "data edited" flag which will come handy here.

2. Klaus, I completely agree with you that highlight jumping back would would detract from the user experience. By your method, clicking on "Jack" in the list field would load Jack's data in the data fields and disable the list field. If the user wants to go to "Mary" without making any change to Jack's data fields, he would still have to click "Cancel" to enable the list field (this is not intuitively obvious to a user). But your method has the virtue of limiting user choice to what is appropriate.

3. This is what I had done to resolve the issue. This takes advantage of the fact that one of the data fields is the "Name" field which displayed the name of the student just as it appeared in the list field. The Name field, of course, is locked. I used this Name field to figure out where the previous highlight was (in the list field) - without using a custom property.

Code: Select all

set the hilitedLine of field "Student Name List" to line lineOffset(field "Name", field "Student Name List")

4. Lastly, a frontscript that captures the mouseUp in the list field (as mentioned in my previous post). It works, but I think is inelegant and disproportionate to the problem.

One of the first three should work for me.

Thanks,
Sri.