Common Anchor Settings?

[SteveDingle]

Heya All,

Finally digging into my framework and removing all the old resizing logic so I can utilize the Anchor property and I was wondering if anyone had ever documented the most common settings. I started doing it myself but thought I would ask.. especailly since I have found some instances where multiple values do what "seems" to be the same thing and I have one setting I can't figure out ;-)

Problem setting scenario: 3 buttons at the bottom of the form, positioned horizontally, the "group" should remain centered horizontally, with the distance between the buttons remaining the same.

Toodles,
Steve Dingle

http://www.dsbusinesssolutions.co.uk

D&S Business Solutions Ltd

 

[ChrisCarroll]

Try this:
Put the three buttons inside a container.
Put container.anchor=260
Make the container transparent and edgeless.

I got 260 by looking at what the builder offered for anchor values for a single button. 260 was 'centred at bottom of form' with no resizing.

 

[MarciaAkins]

Hi Steve.

I was wondering if anyone had ever documented the most common settings.

Check out the Kitbox column in the June 2004 issue of FoxTalk. Andy and I discussed this very topic. The article is called "Anchors Aweigh"



Marcia G. Akins

http://www.TightlineComputers.com

 

[Mike Lewis]

Steve,

One of my little projects that I never got round to doing was to write a document setting out the most common settings.

I'll let you know if I come up with a few, and perhaps you could do the same.

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[SteveDingle]

Heya All,

Chris: Thanks but I really hate having to add the extra layer of a container

Marcia: Thanks

Mike: Seems Marcia and Andy have already done it

Toodles all and Happy Holidays!
Steve

Toodles,
Steve Dingle

http://www.dsbusinesssolutions.co.uk

D&S Business Solutions Ltd

 

[ChrisCarroll]

Noooo, there's nothing wrong with an extra layer of container!

It's a mindset thing. In Fox, we haven't really done (well I haven't really done) flexible/moving layout before.
In Java and coming up now in .Net, flexible layout is the norm. And it's done by nesting containers.

It makes sense when you get used to it. Because:
To take this example, what you're asking is for your left & right buttons to be anchored to a spot at the bottom of a form, but offset left and right. Now, either you are expecting the anchoring framework to include options for this and a myriad other layout choices;
OR you are expecting it to offer you the building blocks (anchor left/right/bottom/centre) which you can use to specify what you want.
But the way the 'building block' approach works is - nesting containers.

A container, after all, is _precisely_ a tool for managing layout anchoring. (The fact that in VFP it can also be a way of composing UI objects into a complex control is by the by).
It represents a way of saying "anchor these 3 components together (by the containers anchor setting) but, having done that, apply the further rule of keeping them equally spaced in a line."

</soapbox>

I've been persuaded anyway - as soon as you think about more and more complex screens, you realise that the 'building blocks' idea is the only way to do it.


Chris

 

[SteveDingle]

Heya Chris,

Thanks for your thoughts, however I generally only use containers when I need to build a 'complex' reusable control, as you mentioned.

The idea of using a container to position something seems abit over the top as it would server absolutely no other purpose than that, positioning. Not sure exactly how the whole 'overhead' concept works, but considering all the PEMs that make up a container, well again, just seems like
too much 'overhead' for me.

Of course, if I'm forced to, I will use one

Thanks again.
Steve

 

[SteveDingle]

Heya,

Just to add before anyone else does.. since it's just buttons I would of course use a command group before putting them in a container

Toodles,
Steve Dingle

http://www.dsbusinesssolutions.co.uk

D&S Business Solutions Ltd

 

[Mike Lewis]

In my humble o, the main reason for using containers is when you want to do something with the controls as a group -- when you're interested in the controls as a whole, rather than the individual components.

For example, suppose you have some address fields in your table. Instead of having maybe five separate free-standing textboxes, one for each line of the address, you might put these into a container, so that you can work with the address as a whole.

If you were to write functions such as "copy address to clipboard", or "send a mailing to the current address", you wouldn't want to know about what controls make up the address -- you just want to work with the address. And, if you ever changed the format of the address (adding an extra line, for instance), you would only need to change the container, not the many forms on which it exists.

I agree with Steve that using a container as an aid to positioning is overkill. In some circumstances, they make good sense; in others, they just add unnecessary overhead and complications.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[ChrisCarroll]

Yo ho,
In proposing a container, I'm not proposing to make a class of it.
I acknowledge that what I say represents a 'new' use of container.
But: the desire for (and ability to properly do) flexible layout is also new.
Hence a new solution (well, okay, a solution nicked from Java).
I submit that to accuse a container of being an overhead or a complication is unfair. Is there _really_ any noticeable overhead in having 3 containers on a form (as compared to say having shapes or lines even nothing at all)?

On the other hand: if you can see a way of doing real flexible layout with less overhead ...

Perhaps my argument on this point would be: There just is no way to do flexible layout without overhead. You can embody the overhead in custom code or in extra containers or in another solution, but the overhead is still there somewhere.

Cheers,

Chris