Using OI7.01.

On a client's system the SIZE property returns an incorrect value for a certain window when it is called as a dialog_box. I'm not sure if it is related to it being called as a dialog box, but when it is called as an MDI_Child, the SIZE property returns the correct values.

The SIZE property of the control that we are trying to retrieve should be 669:@FM:96:@FM:4:@FM:7 but Get_Property incorrectly returns 669:@FM:-1620:@FM:4:@FM:7 Notice that the "y" value should be 96, but is returned as "-1620".

This control is right anchored and invisible, but that shouldn't matter. The SIZE property returns correctly on all our test systems. It is just at the client site that it is incorrect.

Anyone know why this is okay our system, but incorrect on a couple of our client sites?

Thanks,

Ray Chan

Hi Ray,

Is this a multi-page window?

The y co-ordinate automatically changes depending on the page the user is on. Controls on previous pages are given high negative co-ordinates and controls on later pages are given high positive co-ordinates. The formula for this has changed between 4.1 and 7.0.

Only the controls on the currently visible page will have 'normal' xy co-ordinates. The increment/decrement amount per page is based on the desktop area of that user, so will be different from machine to machine.

Revelation can perhaps give you the exact formula for this calculation.

Paul

[img]http://www.vernonsystems.com/images/logo_main.gif[/img]

Paul,

Is this a multi-page window?

Yes this is a multi-page form. We use a standard function to keep "certain" controls on all pages.

In most case, this worked, but notice that it didn't work on all form or all computers. We didn't know why until your explanation, but we did know that the failure occurred after moving from 4.1 to 7.xx.

We scratched and scratched our head. We work around this problem by moving our "KeepOnPage" routine from the CREATE event to the "ACTIVATED" event.

The formula for this has changed between 4.1 and 7.0.

I kinda of remember this when I was researching this problem, but couldn't find the link. Do you know why the change was made?

The increment/decrement amount per page is based on the desktop area of that user, so will be different from machine to machine.

This is more for curiostiy, but why is that. We couldn't really debug the problem using our computers until we got access to the client's system. Then we could really see that things were way out there . Is this a function of the video card? or something?

Hopefully, our change will cover all situtations, all computers, past, present, and future .

Thanks for your response. Really appreciate it,

Ray Chan

I dont believe a 'justified' reason for changing this behavior ever was put forward .. more of a 'cause .. '. Seems that things like this should be enhanced/changed without changing existing coding .. added sysvar or something. Not like we will run out of memory Kind of like the UD ..

but then we just have to keep the code working .. head down Ray .. type type type ..

dsig _at_ sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

=== At 12 APR 2005 03:32PM [email protected] wrote: ===

Dave,

Hey, I think that I will need the formulat for their new calculation

It seems that our fix was incomplete and now has another unexpected effect ;-(( Just discovered this.

As we speak I am typing typing typing….

Yeah it would be super nice if changes could be made without affecting existing code. If not at least some warning or at least warnings that I will understand

RTI, could the formula be made available. I think I need this please.

Ray

You're using frameworks .. (we're playing with it right now) don must have worked through this problem .. ?

dsig _at_ sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

We were using framework before framework was called that. Glad to know that you're using it. I highly recommend it. Have you checked out the OLEs or the System Editor?

Anycase, our KeepOnPage routine is ours, but as posted earlier if you call this window as an MDI child things are okay. However, if we now switch and call it as a dialog box, then BAM! The form is 3-pages and there's something about it that is not getting handled now that wasn't a problem in OI4.x. Maybe we using too many edittables.

I'm sure that with more typing, ingenuity, help, and special secret formula from RTI that we can whip this .

Mr RTI, when you get a chance can you please e-mail us the secret sauce.

Thanks,

Ray

RC] We were using framework before framework was called that. Glad to know that you're using it. I highly recommend it. Have you checked out the OLEs or the System Editor?

Yeah .. trying it out on this conversion. Not yet sure if we will continue with it but saves lots of time. There have been a couple funnies but they are worked out. The editor is much better than the one from RTI. There are some problems with it (more my expectations having used TextPad for so many years) but Kevin has been very good at addressing any 'problems' and looking at some enhancements. I like it when people don't get all fussy when you make suggestions

Well good luck on getting the secret formula .. hope it works out for you.

head down .. type type type .. back space .. type type type

dsig _at_ sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

I agree that it would be nice to have this change documented. We spent a while trying to figure out why our custom size events were suddenly displaying controls in very strange places.

The pageheight difference changes from machine to machine because it is based on desktop resolution that the user has.

The increment/decrement of the y value per page is:

Get_Property( 'SYSTEM', 'SIZE') * 2

Don't ask me why it has the times 2, but this is what seemed to change between 4.1 and 7.0. The y height of System Size seems to be the total screen height minus the Windows Start bar height, minus the title bar height, minus the bottom window border (of OI) height.

Paul

[img]http://www.vernonsystems.com/images/logo_main.gif[/img]

Ray,

There wasn't a change to the SIZE property in 7.x. The change was to the ORIG_SIZE property. SIZE still returns positive numbers.

Sean

Sean,

Maybe there wasn't a change to the Size property, but as pointed out earlier why is Size returning -1620. See below from initial posting:

The SIZE property of the control that we are trying to retrieve should be 669:@FM:96:@FM:4:@FM:7 but Get_Property incorrectly returns 669:@FM:-1620:@FM:4:@FM:7 Notice that the "y" value should be 96, but is returned as "-1620".

Any help or insights that you can provide would be appreciated. Also, I seem to remember that there was an earlier discussion on some change in the form coordinate between OI4 and OI7??? Does this ring a bell?

Any case, thanks!

Ray Chan

SIZE returned negative y values in 4.x and still does in 7.x. It only happens on multi-page windows. Controls on the pages previous to the current page are dynamically changed to the negative y values.

The amount these references are incremented/decremented per page seems to have doubled in 7.x

Paul

[img]http://www.vernonsystems.com/images/logo_main.gif[/img]

Ok, I got it now!

Thanks, I will dig deeper.

Sean

View this thread on the Works forum...