Hi all,

Testing our OI9 app in OI10 and have odd behaviour which seems to be tied to invisible controls. In OI9 we have forms that, when resized, have both visible and invisible objects that are sized and positioned programmatically - these controls are then shown or hidden depending on actions on the form.

Now, it seems in OI10 when an invisible control is resized it is made visible - is this intended?

Cheers, Rich

Hi all,

Testing our OI9 app in OI10 and have odd behaviour which seems to be tied to invisible controls. In OI9 we have forms that, when resized, have both visible and invisible objects that are sized and positioned programmatically - these controls are then shown or hidden depending on actions on the form.

Now, it seems in OI10 when an invisible control is resized it is made visible - is this intended?

Cheers, Rich

Hi Rich,

Yes, we do something similar. Differences we found with the SIZE property concerning portability to OI 10 :

• Need to explicitly set SIZE< 5> = -1 to preserve visibility state (otherwise hidden controls become visible).
• May need to set SIZE< 6> = 1 to Suppress Change Notification. See Size and Position for more info.
• Setting SIZE< 2> needs to retain the yPos:page notation (for subsequent pages). Absolute height does not need to be determined, as it does for OI9.
• orig.struct< 1, pspos_colwide$> no longer always includes the rowbuttons column.

HTH, M@

Vernon Systems

Hi Matt,

Thanks for that - I never thought to try <5> tbh - I believed that was for the form only and not controls within it..!

Nice easy change to make to get that through. Also <6> will be a useful addition as I'm getting form SIZE event triggered 4 times :)

Thanks again,

Rich

Hi Rich,

That is not intended - looks like some sort of a regression bug where it's picking up the form behavior. Will get it fixed.

Regards

Carl Pates

Hi M@,

Setting SIZE< 2> needs to retain the yPos:page notation (for subsequent pages). Absolute height does not need to be determined, as it does for OI9.«

Not sure what you mean by this - can you elaborate more?

orig.struct< 1, pspos_colwide$> no longer always includes the rowbuttons column.«

That was deliberate - it broke the concept of an associated multi-value group with the other column settings so it was moved :)

Carl Pates

» Setting SIZE< 2> needs to retain the yPos:page notation (for subsequent pages). Absolute height does not need to be determined, as it does for OI9.«

Not sure what you mean by this - can you elaborate more?

Actually, looking at this more, that statement can be simplified, and made clearer. SIZE< 2> is the vertical position of a control. In OI9 this resolves to the absolute vertical position from the top of the first page; whereas in OI10 it is the vertical position relative to the top of the page it is on (which is much easier to work with).

In my case, I'm repositioning controls working from the initial positions stored in ORIG_SIZE. For multi-page windows, the vertical position for controls that are not on the first page are stored as yPos:page - where yPos is the vertical position relative to the page, and page is the page number. In OI9, the yPos:page format doesn't work when setting the SIZE property, so I was having to calculate the absolute vertical position from this. In OI10 this isn't necessary - it works with the position relative to the page, and will accept the :page suffix as well.

»orig.struct< 1, pspos_colwide$> no longer always includes the rowbuttons column.«

That was deliberate - it broke the concept of an associated multi-value group with the other column settings so it was moved :)

Yeap, good move :) . In OI9 I was having to work around it ;)

Cheers, M@

Vernon Systems

View this thread on the Works forum...