layout / position issues

[GoogleCodeExporter]

once a control with layout has a position assigned, we can't drag it in
designer. what happens is the control is resized and then allocates another
position in the layout - which is an invalid item in the list. To fix this
we need to modify resized method for controls so that once they have a
layout location assigned they retain it - the only exception to this being
if the layout has been invalidated. Test with mouse toolbar controls -
select one, assign a place then move it.

updating a clone control position does not update position in realtime.
Also drag/drop of clone control position does not work.

when changing position of a control/container then we should create and
assign a new placement object for the control. may need some form of naming
convention to identify unique placements (i.e. those not shared by other
controls). ?? needs some thought...

layouts will present a problem with uncontained controls - there is nothing
to reset the layout for controls that do not specify an index or row/column
explicitly. How can we handle these? Maybe we treat these as being owned by
a default "screen level" container for layout purposes, but not for
rendering... hmm. no, still not right, since each control could be in a
different layout. Needs thought...

refresh display of xml view when layout is selected and its refreshed using
placement tool. may need to add an event callback - similar to
invalidateuiobject that refreshes memo display.

Original issue reported on code.google.com by aretman...@gmail.com on 11 Jun 2008 at 10:08

[GoogleCodeExporter]

add move/size tool updates integration with change history manager - and apply
appropriate RTTI data to the change too. Apply the change on mouse up event.. 
Change
history will likely grow very quickly so may have to dedupe the top item and 
only
update the new x/y values in the change history. do we really need to do this? 
need a
way to store both x and y coords in the same change object. Not so bad with 
mouse up
events, but a pain for keyboard changes.

Actually this happens in other applications so may not be too bad - perhaps we 
just
need to increase the history limit.

Original comment by aretman...@gmail.com on 11 Jun 2008 at 10:41

[GoogleCodeExporter]

Before a layout can be used it must be associated with a container, which 
implies
that all controls within that container must share the same container layout.

However, controls are associated with a named layout which may be different to 
the
one the container is using.

We need to explore the implications of this with a few test scenarios and decide
whether we need to allow multiple container layouts, remove control layout 
naming or
do something else.

Original comment by aretman...@gmail.com on 11 Jun 2008 at 2:44

[GoogleCodeExporter]

designer version 0.0.29 has made some progress on this. Layouts are now 
independent
of containers, so may be used with standalone controls. This tweak has also 
improved
layout allocation reliability, fixing some of the issues reported above.

Original comment by aretman...@gmail.com on 5 Jul 2008 at 4:24

• Changed state: Started

[GoogleCodeExporter]

Resolved in designer version 0.0.32. See release notes.

Original comment by aretman...@gmail.com on 3 Mar 2009 at 4:46

• Changed state: Fixed