Query regarding 'jumping' components

[CHeighlund]

I apologize if the topic isn't quite clear enough. I'm working with a form where I'm trying to create multiple 'blocks' of form that appear on screen. (That is, there are multiple segments that can fill the same slot [via run-time "*.align := alClient"].) In trying to get enough room on the form to work with these, I'm shifting everything over sideways and down, vastly expanding the size of the form. (These will all be invisible during runtime, except for whatever one is being shown at the moment.)

I've got three blocks up so far, all of them identical in base structure, and I'm running into a rather strange problem. Each 'block' consists of a single groupbox, with three more groupboxes on it (alLeft, alClient, alRight). With the exception of the first groupbox (the one I originally dropped into place on the screen) and the three on it, whenever I drop a component on the boxes, it seems to disappear. The name appears in the treeview, and clicking on it there does bring up the properties. It's here the problem lies, although how I'm not quite sure; either the Left value or the Top value is always something screwy; I've seen three or four negative multi-hundred (-700 < x < -400) values, and similarly sized, sometimes even larger, positive values. (I've seen a couple of positive values > 1100.) This only appears to happen when the new component is dropped on a group box, or when I try to move a component already sitting on a group box.

Does anyone have any solutions as to what might be causing this, or how I can get it to stop? It's somewhat annoying trying to work with the components when an accidental slight shift in position can make them vanish.

 

[roo0047]

I may be wrong, but to my knowledge, you should have no negative values unless you are using a dual monitor system.

Right-click on the form and select "View as text". Look at the object nesting. You may find that some child objects don't belong to the same parent objects you may think they do.

Should you decide to start moving things around in text mode, be sure to make a file backup of your .DFM Without a lot of practice, it's easy to get lost and make a mess, in which case you'll want that backup file.

Good luck with it.

Roo
Delphi Rules!

 

[roo0047]

Any (top or left) value less than zero or greater than its parents width is off the form (or parent object).

Often viewing the form full screen will reveal hidden objects.

Roo
Delphi Rules!

 

[Duoas]

Yeah, that sounds like a bug in the IDE to me. When you edit the left/top to a sane number does it appear in the groupbox?

I've done exactly what you are doing, and it does take a little getting used to. If viewing fullscreen like Roo suggests isn't enough real-estate, it helps to go turn on the form's scrollbars and use them while editing, and turn them off in the FormCreate method.

Hope this helps.

 

[CHeighlund]

@Roo:
Viewing the form fullscreen doesn't help me out that much.
There are two 'layers' of groupbox component. The highest layer (directly under the form itself in the tree) are all of a static size - width 673. Height varies between the boxes, but the largest one has a height value of 352.
The second layer of groupbox components are placed on the upper layer, three per box. The left and right ones are width 230, and are set to alLeft and alRight, respectively. The middle one is simply set to alClient.

The components that are disappearing on me with the wild values are the items (checkboxes, labels, etc.) placed onto these second-layer groupboxes. Since there's only so much real estate inside the boxes (and the item positions [width/height] are marked relative to the box's upper-left corner, apparently), the wild values makes them disappear and I cannot simply 'resize' the screen; I'd have to resize the components as well.

@Duoas: Yes, the missing stuff does reappear in the box when given reasonable values. Until the next time you accidentally move it, when it vanishes again with another wild number.

@Both: Thanks for the suggestions; I'll see whether or not they work out.

 

[roo0047]

If you have that many "Visual Components", and do not plan to have them all visible (as in viewable) all at once, the best approach is to use Frames. Design each entire frame individually. Optionally, and save them to a repository. Break your form up into the number of [blue]Panels[/blue] you will need. (Nothing else on the form except menus, toolbars, statusbar, etc.) This all requires planning in advanced.

At run-time:
[ul]
[li]Resize/hide/show the [blue]Panels[/blue] in preparation for the frame.[/li]
[li]Create the frame.[/li]
[li]Set the frames Parent property to the appropriate Panel[/li]
[li]Set the frames Align property to alClient[/li]
[li]Free it when you're done with it.[/li]
[li]Again, resize/hide/show the [blue]Panels[/blue].[/li]
[li]Piece of cake![/li]
[/ul]
I realize this may require you to start over from scratch, but it sounds like your form is hosed enough that than might be a good idea anyway.

As complicated as this may sound, really it's not, once you get the hang of Frames. It's much easier than trying to work with and visualize what it will look like while in the IDE. The advantage is that all components on each frame will be positioned relative to the TLHC of the frame.

I can post some code from one of my projects that was done that way if you're interested.

I'm using D7 and assuming later versions still support frames.

Roo
Delphi Rules!

 

[CHeighlund]

@Roo:

I am also using Delphi 7, and if you wouldn't mind, I would greatly appreciate the chance to see what you are talking about. At the moment, I really don't have a clue what you mean, but I would be interested in learning about it.

 

[roo0047]

To get started, from Delphi menu, select File > New > Frame (not Form). Then, look at delphi help:

TFrame is a container for components; it can be nested within forms or other frames.

Unit

Forms

Description

When you create frames, they are implemented as descendants of TFrame.

A frame, like a form, is a container for other components. It uses the same ownership mechanism as forms for automatic instantiation and destruction of the components on it, and the same parent-child relationships for synchronization of component properties. But frames can be nested within forms or other frames, and they can be saved on the Component palette for easy reuse. After a frame is created and saved, it continues to function as a unit and to inherit changes from the components (including other frames) it contains. Moreover, an embedded frame continues to inherit changes made to the frame from which it is derived.

The first thing you'll notice is that the unit will [red]NOT[/red] contain the global var...

var 
  Frame1: TFrame;

... like Forms do...

var 
  Form1: TForm;

You have to define it yourself in the calling Form.

Look at my code here: thread102-1428872

You'll find others by searching this forum for "Frame" and "TFrame".

Frames are great because with a single panel you can load frame after frame after frame. To the user, it looks like flipping pages in a book. Let me know if you need any help with your code when you get it going.



Roo
Delphi Rules!