Re: Setting Geometry on cloned objects

[Kevin Miller]

On 8/10/02 10:07 am, Monte Goulding <[EMAIL PROTECTED]> wrote:

> I find the geometry manager covers just about everything I need, however, I
> can see the need for a public API for setting the geometry manger's custom
> properties in script.

Request noted.

Thanks,

Kevin

Kevin Miller <[EMAIL PROTECTED]> 
Runtime Revolution Limited - The Solution for Software Development
Tel: +44 (0) 870 747 1165.  Fax: +44 (0)1639 830 707.

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Setting Geometry on cloned objects

[Monte Goulding]

> It would be a useful contribution if anyone would write a kind of
> GeoMan stack that just adds a properly working resizeStack handler to
> the stack script.
>
The question needs to be asked: Why would one trust this "useful
contribution" any more than the Geometry Manager?

I find the geometry manager covers just about everything I need, however, I
can see the need for a public API for setting the geometry manger's custom
properties in script.

Cheers

Monte

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Setting Geometry on cloned objects

[Terry Vogelaar]

Bob Rasmussen heeft op dinsdag, 8 okt 2002 om 07:20 het volgende 
geschreven:
>
> Short of writing my own Geometry Manager, does anyone have any other 
> bright
> ideas?

Because I never trust the GeoMan, I always use 'resizeStack'. To give 
an example, I pasted the script of a stack that uses this technique. 
The stack has a divider line that sets it's own 'divid' custom prop and 
also calls 'arrangeElements'. It needs some typing, but it is quite 
simple and gives much more predictable behaviour than the GeoMan.

It would be a useful contribution if anyone would write a kind of 
GeoMan stack that just adds a properly working resizeStack handler to 
the stack script.

on resizeStack
   arrangeElements
   pass resizeStack
end resizeStack

on arrangeElements
   put the divid of btn "Divider" into perc
   put the width of this stack into lWidth
   put the height of this stack into lHeight
   put round((perc*(lWidth-365))+120) into L40
   if L40 < 120 then put 120 into L40
   if L40 > (lWidth-245) then put (lWidth-245) into L40
   set the rect of btn "Divider" to L40-7&",52,"&L40+1&","&lHeight-4
   set the rect of btn "OTNT" to "4,52,"&L40-10&","&lHeight-4
   set the rect of btn "showwhich" to 
L40+4&",104,"&lWidth-4&","&lHeight-4
   set the rect of fld "books" to "10,76,60,"&lHeight-10
   set the rect of fld "history" to "62,76,"&L40-14&","&lHeight-10
   set the rect of fld "shortcutnumbers" to 
L40+6&",129,"&L40+26&","&lHeight-10
   set the rect of fld "groups" to 
L40+26&",130,"&lWidth-10&","&lHeight-10
   set the rect of fld "head" to L40+4&",52,"&lWidth-4&",74"
   set the rect of fld "subhead" to L40+4&",77,"&lWidth-4&",99"
end arrangeElements


___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Setting Geometry on cloned objects

[Bob Rasmussen]

This note is about making your own calls to undocumented Geometry Manager
functions, rather than using the Geometry Manager stack.  Normally, I wouldn't
fiddle with undocumented interfaces, but in this case it seems like the right
thing to try.

I have a stack in which I need to clone a particular group an arbitrary number
of times.  The original group has a few controls in it.  The group and its
controls have been given Geometry Manager settings so they will resize
automatically to fit the width of the card. Some of the controls refer to the
group they are in. Some refer to other controls in the group.

I would like to arrange the clones below the original group in a column, such
that the clones have the same resizing behavior as the original (plus fancier
things if I get this to work).  Cloning, however, duplicates all the geometry
properties of the originals, including any object references in them.
Therefore, the geometry properties in the clones all refer back to the original
group and its controls, rather than to their own peers in the clone.

I have thoroughly reverse engineered the Geometry Manager stack, and I think I
know how to emulate what it does, but so far this has not worked.  I end up with
no geometry adjustment at all, and other things start acting a little weird.
I've tried doing it the "legal" way with calls to the undocumented
revSetGeometryObject, revGetGeometry and revSetGeometry, as well as to the
documented revCacheGeometry and revUpdateGeometry.  I've also tried setting
cRevGeometry properties directly.  Neither method works reliably.  I must be
missing some small detail.

This leads me to the following questions:

1.  Has anyone out there ever successfully used these undocumented interfaces?
Can you tell me what the incantation is?

2.  If I ever figure this out, am I wasting my time, since future versions of
Revolution may not work the same way on these undocumented interfaces?  Are
there plans to document these interfaces (or some new version of them)?

3.  Would anyone be interested in what I've managed to find out on my own so far
about these undocumented features?

4.  Short of writing my own Geometry Manager, does anyone have any other bright
ideas?

Thanks in advance.

RR


___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution