Making "Wells": Whose Control Is It Anyway?

[Jerry Balzano]

Thanks to Richard and Xavier for their responses to my query.  What I 
ended up doing, along the lines of Richard's suggestion, was to
	get the long ID of field X
	delete word 1 to 4 of it  -- deletes "field ID nnnn of"
	put it into altOwner  -- I may turn this into a custom property, in 
case I need it again

and now "altOwner" contains what should have been the long ID of the 
owner (but wasn't).  (P.S. this is definitely a bug!!)

While I have the precious time and attention of those (many) who are 
more expert in Rev than I:  I'm still struggling with what looks like 
the inelegance of my solution to a kind of pseudo dragging-and-dropping 
of these groups.

Here's the situation: say the user is dragging a green group.  Other 
grouped controls on the card have green "slots" (actually fields with 
different text color) that need to signal that they will "accept the 
drop" of the green group, which they do by hiliting their border 
(actually turning off their threeD property temporarily).  Since I have 
an object attached to my cursor (the green group I'm dragging), no 
handlers in the other controls on the card will get triggered (right?), 
so I seem to have no choice but to iterate over the controls, and do a 
test inside the original green-group handler (or — gasp — inside an 
"idle" handler) like
	if the mouseLoc is within the rect of control i
	then set the threeD of control i to false

I foresee this "solution" scaling badly as the number of controls on 
the card increases.  But I don't at the moment see a better one.  Is 
there?

Thanks again to listmembers for sharing your expertise with me,
Jerry


> On Feb 22, 2005, at 9:47 AM, Richard Gaskin wrote:
>
>> Jerry Balzano wrote:
>>> I have a stack where I use grouped objects as “wells” from which 
>>> users can drag a copy for their own use.  I need to be able to refer 
>>> to the owner of these grouped objects but it’s also important for 
>>> the groups to have names.  The copied group has the same name as the 
>>> original, but this is good, because the name is meaningful.  Anyway, 
>>> every newly created group has its own distinctive ID, so there 
>>> should be no problem, right?  Actually, wrong.  If I have a group 
>>> called “mygroup”, say ID 1004, which I copy and paste to create a 
>>> new instance of “mygroup”, say ID 1015, my attempts to find out the 
>>> owner of the objects in the second group always returns the owner of 
>>> the first group instead.
>>>
> ...
>>> What can I do about this?
>>
>> Short term: forget "the owner" and use the long ID instead, dropping 
>> the part before " group ID ".
>>
>> Long term:  All object references returned by the engine MUST be in 
>> their universal ID-based form unless the user specifically requests a 
>> potentially ambiguous alternative (like "long name").
>>
>> Therefore I would consider this a bug, and would gladly vote for it 
>> in Bugzilla.
>
> On Feb 22, 2005, at 9:55 AM, MisterX wrote:
>
>> Something like this was reported some time ago...
>>
>> Have you tried the AltID or using a customProperty?
>>
>> put the name of grp x into thisgroup
>> set the TagID of thisgroup to NextIDNumber