tiny mystery

Charles Hartman charles.hartman at conncoll.edu
Sun Oct 30 09:56:13 EST 2005


--but now I'm finding the same problem cropping up later,farther down.

Example: user selects a line in the list-field and clicks a button to  
"delete this entry". The deletion works fine, and the hilited line  
disappears from the list (and, behind that, the record that it  
represents in the database is deleted).

But where can I put a line to DE-select (unhilite) all lines in the  
field after that? Putting it at the end of the handler that does the  
deletion doesn't work; putting it in the handler that calls the  
deletion handler, after the call, doesn't work. In both cases, I end  
up with the blank line at the end of the (now shortened) list hilited.

So there's something general I don't understand. What's sneaking in  
and puting hilites where I haven't asked for them in a script and the  
user hasn't clicked anything new?

Charles Hartman

On Oct 30, 2005, at 9:40 AM, Charles Hartman wrote:

> Excellent, that does it: openStack rather than preOpenStack. Thanks!
>
> Charles
>
> On Oct 30, 2005, at 8:55 AM, Dave Cragg wrote:
>
>
>>
>> On 30 Oct 2005, at 12:56, Charles Hartman wrote:
>>
>>
>>
>>> I've got a dialog substack that includes two fields with  
>>> listBehavior set to true. I fill them up from scripts -- a  
>>> preOpenStack handler for one, and for the other an "on  
>>> selectionChanged" handler called when something from the first  
>>> list one is selected.
>>>
>>> I don't want anything to be selected in either one until the user  
>>> selects something. So at the end of both list-filling handlers, I  
>>> include the line
>>>
>>>         set the hilitedLine of fld "oneOfTheListFields" to 0
>>>
>>> It works in one (the one filled after the user selects something  
>>> from the other) but not in the one filled by the preOpenStack  
>>> handler. That list shows a hilite on the blank line after the  
>>> last item in the list. How do I get rid of it??
>>>
>>>
>>
>> One way round this would is to put the above line in an openStack  
>> handler instead of preopenStack.
>>
>> Another way might be to set the traversalOn property of the fields  
>> to false. (Which might not be what you want.)
>>
>> I think the problem is that Rev will focus on the first control  
>> with traversalOn *after* the preOpenStack handler runs. If ths  
>> control is a list field, it will hilite one of the lines (not sure  
>> why it's the last line in your case, it's the first here).
>>
>> Cheers
>> Dave
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>




More information about the use-livecode mailing list