Menu

#1105 getPos gives returns wrong result

ooDialog.4.2.0
closed
ooDialog (58)
none
1
2012-08-27
2012-08-21
No

getPos seems to give lower x/y coordinates than it should. The sample program below illustrates the problem. Run it using rexxhide. At first call, move the dialog window to the lower right corner of the screen, and press enter. Repeated calls makes the window move towards the upper left corner until the x/y coordinates are 1/1.

a = .mydialog~new(dlgStem.)
if a~initcode = 0 then a~execute("SHOWTOP")
a~deinstall
exit

::class mydialog subclass userdialog
::attribute loc private
::method init
forward class(super) continue
self~loc = .properties~new
self~loc~load(data.txt)
x = self~loc~at("locx")
if x = .nil then x = 1
y = self~loc~at("locy")
if y = .nil then y = 1
self~create(x,y,200,200,"getPos test","NOMENU VISIBLE")

::METHOD ok
self~ok:super()
self~loc["locx"] = word(self~getPos, 1)
self~loc["locy"] = word(self~getPos, 2)
self~loc~save(data.txt)
self~finished = 1
return self~finished

::requires "oodwin32.cls"

Discussion

  • Mark Miesfeld

    Mark Miesfeld - 2012-08-21
    • labels: --> ooDialog
    • assigned_to: Mark Miesfeld
    • pending_work_items: complete --> none
     
  • Mark Miesfeld

    Mark Miesfeld - 2012-08-21

    Yes, getPos() is inherently broken. You should start using ooDialog 4.2.0, which will give you ways to avoid several of the broken things in ooDialog that can't be fixed.

    You can download ooDialog 4.2.0 from here:

    https://sourceforge.net/projects/oorexx/files/ooDialog/4.2.0%20%28beta%201%29/

    Although it is labeled a beta, it is just about to be released and it is doubtful there will be any code changes. My plan is for the official release to be the last week in August.

    The ooDialog installation will install over the top of your current ooRexx installation allowing you to upgrade ooDialog without waiting for a new release of ooRexx.

    The doc for ooDialog 4.2.0 explains why getPos() is inherently broken. The basic reason is that getPos() uses factorX and factorY to convert between pixels and dialog units. The values of factorX and factorY are incorrect in a modern version of Windows. They may have been correct for Windows 3.1 when ooDialog was first written, but the values are simply wrong now. The whole concept of factorX and factorY is flawed to begin with.

    ooDialog 4.2.0 has a new method, getRealPos() which will give you the ability to get accurate positions. The other new method, moveTo() will allow you accurately move to the position you specify.

     
  • Mark Miesfeld

    Mark Miesfeld - 2012-08-21

    I've attached a program, based on your example that shows the desired outcome. That is, each time the dialog is executed it opens at the exact same spot as it was closed.

     

    Last edit: Mark Miesfeld 2012-08-21
  • Mark Miesfeld

    Mark Miesfeld - 2012-08-21
    • status: open --> pending
    • milestone: None --> ooDialog.4.2.0
     
  • Mark Miesfeld

    Mark Miesfeld - 2012-08-21

    I'm putting this into pending, with the idea that it is fixed in ooDialog 4.2.0.

    But really, getPos() is not fixed and won't fix. The design of getPos() makes it inherently inaccurate. That can't be changed because I've seen many programs that take the result of getPos() and then make small adjustments to try and correct its inaccuracy. Fixing getPos() can't be done without changing the results returned by every method that uses factorX and factorY, which is a lot. The would change the behavior of really a lot of existing programs.

    Rather, ooDialog 4.2.0 gives you the ability to do what you want using alternative, accurate methods. The program I attached show how to achieve what you want using the correct methods.

     

Anonymous
Anonymous

Add attachments
Cancel