#168 Progress bar method setpos not working

4.1.0
closed
ooDialog (31)
5
2012-08-14
2010-01-12
oorexxpert
No

Setpos in previous versions supported non-hole number for the setpos method. In 4.0.0 a non-whole number generates message:

Error 88.907: Argument 1 must be in the range -2147483648 to 2147483647; found ".5"

There is also to mention of whole numbers in the document. Attached is testcase.

I will have to back off 4.0.0 until fixed.

Discussion

  • oorexxpert

    oorexxpert - 2010-01-12

    Progress bar testcase.

     
    Attachments
  • Mark Miesfeld

    Mark Miesfeld - 2010-01-14

    You can only set the position of a progress bar to an integer value. From MSDN:

    PBM_SETPOS Message


    Sets the current position for a progress bar and redraws the bar to reflect the new position.

    Parameters

    nNewPos
    Signed integer that becomes the new position.

    In ooDialog, from 4.0.0 on, there is a much more rigorous check that arguments to methods are correct. When they are not correct, a syntax condition will be raised.

     
  • oorexxpert

    oorexxpert - 2010-01-14

    Why does it work in 3.2? I shouldn't have to access MSDN to know how to code it in REXX. If MSDN requires an integer, the OODREXX document should say it has to be an integer.

    Besides, the REXX i knew hid a lot of that operating system stuff and was usually not so strict. If it has to be an integer, REXX should handle that...it can't make an integer from a REXX

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-01-14

    John,

    (I'm thinking that oorexxpert is John R Bodoh, correct me if I'm wrong.)

    There is a large range of issues here and rather than go deeply into them in this bug report, it would be preferrable for you to start a conversation on the ooRexx developer's list where it is likely that more people will particpate. If you don't start the conversation, I will this weekend.

    Briefly some of the issues are:

    • In fact this does not work on 3.2.0. If you set the position to .5, the position will not be .5

    • The documentation for ooDialog is still mostly what IBM wrote. The ooDialog documentation as recieved from IBM was in many parts misleading, incomplete, or flat out wrong.

    • Except for a few rare cases, every number in ooDialog is a whole number. So, for the doc, I can see that a single blanket statement should be added saying that unless explicitly documented otherwise, all numbers are whole numbers. But, where to put that in the doc. Most people don't read the doc that well anyway.

    In addition, going forward, this syntax condition is going to be raised anywhere you are using non-whole numbers for arguments that are integers. For that reason, alone it would be good to discuss this on the developers list and then later maybe on the RexxLA list.

    • In older versions of ooDialog many times things did not work as expected and the user had no clue as to why. A large reason for this was the use of incorrect arguments. In many cases, the only way I could figure out what was wrong was to laboriously trace through the source code. Going forward I intend to raise syntax conditions for incorrect arguments. That way, I can tell right away what is wrong.

    • Finally, this issue opens up the very fundamental question: Prior to ooRexx 4.0.0, ooDialog was mostly stuck at a Windows 3.0 level, certainly stuck at Window 95. The question is should it stay stuck at Windows 95, or move forward to Windows 7.

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-01-14

    John,

    Your test program is a perfect example showing that setting the postion of the progress bar to .5 does not work under 3.2.0.

    Change the range of the progress bar in you test program to 0 to 5.

      curPB~SetRange(0,5)
      curPB~SetStep(10)
      curPB~SetPos(.5);
    

    Then a position of .5 is 1/10 of the length of the progress bar, something easily discernible by the human eye.

    Run the program and there is no mistaking the fact that the progress bar does not have 1/10 of its length colored.

    Under 3.2.0, the ooDialog programmer would have no way to understand why this doesn't work. Unless he understood C well and looked closely at the source code.

    Under 4.0.0, the raised syntax condition tells the programmer exactly what the problem is.

    I totally agree with you that the doc could be improved. Especially the users should be told that numbers in ooDialog are whole numbers.

     
  • oorexxpert

    oorexxpert - 2010-01-14

    It's possible I did not see the behavior you described in your note. However, I have been using it under 3.2.0 for a few years and it always worked (I say the slider moving...so I thought it was working. All I know is that on 4.0.0 it raised an error condition and before it didn't. That, along with the poor documentation (which mentions nothing about integers), led me to the conclusion that there was an error. Fixing the documentation will be OK.

    I still think it would have been line with REXX thinking that the code would have just rounded the number and be done with it.

    I have noticed that same sort of thing with the other oodialog methods. My thinking is that a program ought to either work or give an error message. There doesn't seem to be much validation as to whether a method has the correct parameters nor issued from from the right method within a dialog. For example, a method might have to be issued from the RUN method for it to work, If you invoke it from, let's say the INITDIALOG method, the expected effect doesn't happen. Can't a method check to see if it is being invoked from the proper place and give an error if not in the right place? This is the hardest part with developing dialogs and I waste more time trying to figure out why an effect didn't happen...just didn't happen.

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-01-20

    John,

    As I said earlier you've raised a number of issues here. I intend to respond to all of them over time, I'm just a little busy. Nothing I say from here on out is meant to indicate that the docs should not be fixed to point out that numbers in ooDialog are always whole numbers unless explicitly stated otherwise.

    • "All I know is that on 4.0.0 it raised an error condition and before it didn't."

    Please take the time to read Chapter 2 section 2.4 - ooDialog 4.0.0 and the future in the ooDialog doc. Especially the part on Syntax errors which directly speaks to this behavior.

    • "I still think it would have been line with REXX thinking that the code would have just rounded the number and be done with it."

    Try running this simple program:

    / Find the average middle word in a series of
    * lines and display them
    /

    line1 = "One fine sunny day I went to work happy."
    line2 = "One day I went to work."

    numLines = 2
    numWords = line1~words + line2~words
    avgPos = numWords / numLines

    say "Middle word in line 1:" line1~word(avgdPos)
    say "Middle word in line 2:" line2~word(avgdPos)

    The interpreter doesn't round to a whole number and be done with it. It rasises a condition. My belief is that I'm moving ooDialog to be more in line with Rexx thinking, rather than the opposite.

     
  • oorexxpert

    oorexxpert - 2010-01-21

    I will now accept that I have to change my code to ensure that I am using integers. Thanks for fixing the docs.

    Your example program is no where near the same thing. Your program finds the middle word number which is obviously an integer...when you count things, you count in integers...it's a count. The position to set the progress bar is a measurement...which can certainly be a fraction. Since that is an obvious interpretation of what "position" means and the lack of any clear definition in the book, it is natural to presume that the value that is a fraction should be permitted.
    People that develop REXX should not presume that the user coding it is also an expert in Windows GUI, or C++..because I certainly am not an expert.

    Thanks again,

    John

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-02-26

    Committed revision 5646.

    For the 4.0.1 bug fix, revision 5646 adds a term definition for number that explains all numbers are whole numbers.

    The doc in trunk for ooDialog is being restructured and already includes a good discussion on numbers to prevent confusion.

     
  • oorexxpert

    oorexxpert - 2010-02-26

    Will there also be a link from places like the progress bar description to this term definition?

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-02-26

    I don't intend to put a link to it in every method that takes a number for an argument in the 4.0.1 docs. So the answer is no. <grin>

    I'll confess that I seem to have a blind spot here. I can't imagine thinking that any of the numeric arguments can be anything other than whole numbers, unless the doc specifically stated that they were not whole numbers. That's my problem. You've pointed out to me I have blind spot here.

    The next feature update of ooDialog has a lot in it that needs to be documented. I'm right in the middle of doing that and I don't want to spend time on the 4.0.1 doc, where there is no change to ooDialog.

     
  • Rick McGuire

    Rick McGuire - 2010-02-26

    Other portions of the documentation use very consistent terminology for numeric arguments. Generally, this will be things like number (i.e., any valid number), whole number, positive whole number, negative whole number, etc. As long as you use this consistent terminology, there's no need for a link to any other explanation.

     
  • oorexxpert

    oorexxpert - 2010-02-26

    I know now what it is supposed to be. The hang-up I had is that the values were refered to as numbers. In my mind I implied that meant a REXX number which of course can be much more that whole numbers.

    Thanks

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-02-26

    That's a good point Rick. Since I'm heavily revising the ooDialog doc, involves a lot of reading the current doc, I'll keep in mind to look for inconsistent terminology regarding numbers, and fix it.

    John, for the next release after this bug fix release, the ooDialog doc should be better, maybe much better. I just don't want to spend any time on the 4.0.1 branch of the doc, when the main branch of the doc has already been much rewritten.

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-10-11

    Committed revision 6272. for 4.1.0

     
  • Mark Miesfeld

    Mark Miesfeld - 2010-12-05

    This item is fixed in the 4.1.0 release.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks