new trick, for me

[Peter Brigham MD]

On Mar 4, 2011, at 2:17 PM, Bob Sneidar wrote:

> Is the field a part of a background group? A background group  
> belongs to a stack, not to a card. (I might be wrong but I doubt  
> it ;-)

"belongs to" is what sense? The owner of the background group is the  
card. Can you say what you mean operationally?

> Also try:
>
> send "put the long id of control 76" to card 1 of stack <myStack>
> get the result
> What does that produce?

the result is empty
executing just the first line gives (for some reason) just the short  
name of the control. I'm not even going to try to decipher that anomaly.

> On Mar 4, 2011, at 11:04 AM, Peter Brigham MD wrote:
>
>> It appears not to trigger openCard.
>>
>> FYI, the reason that I needed to do this is that I am trying to do  
>> something with long id's and found what seems to be a bug in how  
>> the engine handles this. If I do this while on the first card of  
>> the stack:
>>
>>  put the long id of control 76 of card 1 of stack <myStack>
>>
>> I get something like this:
>>
>> field id 1051 of group id 1045 of group id 1004 of card id 2276 of  
>> stack "PDdata" of stack <stackPath>
>>
>> But if I move to any other card of the stack, and execute the same  
>> command, I get:
>>
>> field id 1051 of group id 1045 of group id 1004 of card id 2675 of  
>> stack "PDdata" of stack <stackPath>
>>
>> Note that the card id number in the long id is different, depending  
>> on which card is current -- despite that fact that I asked  
>> specifically for "the long id of control 76 of ***card 1*** " both  
>> times.
>>
>> I know that occasionally executing commands via msg box give  
>> anomalous results, but that appears not to be a factor here.
>>
>> So I need to be on the same card of the stack every time I fetch  
>> long id's for controls of that stack, or else my handlers won't  
>> work properly.
>>
>> Bug, or what?


This still strikes me as a bug.

-- Peter

Peter M. Brigham
pmbrig at gmail.com
http://home.comcast.net/~pmbrig