No announcement yet.


  • Filter
  • Time
  • Show
Clear All
new posts

  • PB9: GRAPHIC SCALE prb I got

    Hi folks.

    Now that I know for sure that my Windows programming skill are very lightweight, I have to ask you about this problem.

    I use GRAPHIC SCALE to create a graphic window with special coordinate system. One notable thing is that I have the X axis reversed (positive end points to the left). Something that worked for me in 8.03 got me some more gray hair with 9.0.

    I tried to construct a reasonably simple example to demonstrate my source of gray hair:

    #DIM ALL
    ' PBWin 9.00.0085 !
    %IDC_GRAPHIC_VIEW = 5000
    GLOBAL grafsize_x,grafsize_y AS LONG
      LOCAL hDLG,desksize_x,desksize_y AS LONG
      LOCAL x1,y1,x2,y2,z AS SINGLE
      DESKTOP GET CLIENT TO desksize_x,desksize_y
      grafsize_x = desksize_x * 0.7: grafsize_y = desksize_y * 0.7
      DIALOG NEW PIXELS, 0, "testing", , , grafsize_x, grafsize_y, %WS_CAPTION OR %WS_SYSMENU, 0 TO hDLG
      CONTROL ADD GRAPHIC, hDLG, %IDC_GRAPHIC_VIEW, "", 0, 0, grafsize_x, grafsize_y
      ' these needs to be 0's here
      x1 = 0
      y1 = 0
      ' add or decrease one or both grafsizes "fixes" axis reversal
      x2 = grafsize_x '+1
      y2 = grafsize_y '+1
      ' x axis reversal !!
      GRAPHIC SCALE (x2,y1) - (x1,y2)
      DIALOG SHOW MODAL hDLG, CALL ShowGraphicsProc
          ' in standard (=unreversed x axis) coordinate system result of this point to the right
          GRAPHIC LINE (grafsize_x*0.1,grafsize_y*0.2) - (grafsize_x*0.8,grafsize_y*0.35), %RED
          GRAPHIC LINE STEP - (grafsize_x*0.4,grafsize_y*0.7), %RED
              CASE %IDCANCEL
                  IF CBCTLMSG = %BN_CLICKED THEN
                      DIALOG END CBHNDL
                  END IF
            END SELECT
    In the above example when I run it, the result points to the right (which it shouldn't with reversed x axis). Add 1 to either of the upper grafsize values "corrects" the result. Is there a logical problem somewhere ?

    At least GRAPHIC LINE and POLYGON seems to suffer from this for me.

    cheers.. aSa C[_]

  • #2
    Hello Ari,

    I took a quick look at this and I think I have your answer. Graphic Scale is looking for Single Precision floating point variables ...not Longs.

    Try changing:

    GLOBAL grafsize_x,grafsize_y AS LONG


    GLOBAL grafsize_x,grafsize_y AS SINGLE

    That seems to take care of the problem.

    Good luck!


    • #3
      Hello again, Ari ...

      Looking a little closer there would be one other little problem. Dialog New and Control Add Graphic DO want to see Long Integers ... so you might want to keep the Globals that you had already assigned for that purpose and use a different set of Single variables for Graphic Scale.



      • #4
        Thanks for the idea, but.. I thought that when I have x1,y1,x2,y2 defined as singles, those longs values would be automatically translated in to single values too (?). But I'll try test this myself too and see how it is.

        cheers.. aSa C[_]


        • #5
          Sorry ... yes, you are correct. (I did not look closely enough).

          However, since changing the Global variables from Long to Single DID have an effect on the problem, you may want to try looking at the values of the variables as they are assigned.

          I'm at work now (which is the main reason that I did not look at this closely enough), but I'll see what I can do during lunch or after work.



          • #6
            Jerry, your tip really DOES change the behaviour, but I just don't understand what is behind of this.

            I used these changes:
            • GLOBAL grafsize_x,grafsize_y AS SINGLE
            • DIALOG NEW PIXELS, 0, "testing", , , CLNG(grafsize_x), CLNG(grafsize_y), %WS_CAPTION OR %WS_SYSMENU, 0 TO hDLG
            • CONTROL ADD GRAPHIC, hDLG, %IDC_GRAPHIC_VIEW, "", 0, 0, CLNG(grafsize_x), CLNG(grafsize_y)
            I used CLNG() for proper (forced) type casting for the dialog and control lines.

            Anyway in my eyes, this is a weird glitch (at least until I understand why..)

            cheers.. aSa C[_]


            • #7
              I've checked Ari's code and I think he's found a problem with PB9 that wasn't in PB8. Ari, I would recommend you send this in to PowerBasic Support for their review: [email protected].

              With respect to LONG and SINGLE arguments, I believe the LONGs get promoted to SINGLEs, so there's no problem there.


              • #8
                Ok, let's take a look at this ...

                Starting back with your original code, change this lines:

                x2 = grafsize_x '+1


                x2 = grafsize_x * 1.00001 '+1

                Now, the graphic is pointed to the left again.

                Odd ... my only guess is that somehow that statement is recasting X2 as a Long and perhaps doing that floating point multiplication keeps it as a Single.

                also ...

                x2 = grafsize_x + .00001 DOES NOT work, yet

                x2 = grafsize_x + .0001 DOES ...

                Anyway, that's my best guess at the moment.



                • #9
                  Yesterday (at midnight of course) I had an idea that there some fance optimization going on with the GRAPHIC SCALE function. You see it's very close to 1:1 so why bother doing the scale process at all (=optimization logic is missing the fact that x axis is reversed.. ).

                  I'll see if there's any better ideas around for a while and then let the support team know about this .. hmm .. feature.

                  Thank You to You all so far..

                  cheers.. aSa C[_]


                  • #10
                    I'll make one more observation and then I'd better stop (before I confuse the issue any further)...

                    For the moment, assume that desksize_x returns a value of 1024 (it does on my machine). Then when you multiply by 0.7 you get 716.8 which becomes 717 when placed into the Long variable grafsize_x.

                    Lower in the code, I set x2 = 717 and the problem persists, however when I set x2 = 716.8 it seems to work just fine. The problem appears to surface when the value passed to Graphic Scale just happens to be an integer value no matter what the variable is defined as.

                    So, I have to agree with Charles at this point.

                    I supose you could detect when the value is an integer value and then offset it slightly as a workaround for the time being (depending on the accuracy you need).



                    • #11
                      Ok, this has been bugging me, so I can't resist mentioning one more observation ...

                      I tried a lot of integers for the X2 value going into the Graphic Scale command and so far only 717 seems to cause the problem. So I got to looking at this magic number ...

                      Using grafsize_x and grafsize_y, you are setting the size of the Graphic Control to exactly the same size as the Dialog itself. I have no idea if there is a problem with doing this, but when I set the Graphic Control to be one pixel less (e.g. grafsize_x - 1 and grafsize_y - 1), the problem seems to go away (at least for the few attempts that I have been able to try). Obviously there is a lot more testing to be done to see if this really is where the problem is ... but you might want to give it a try.

                      I'll do some more digging this evening.



                      • #12
                        Hi Ari,

                        I've been chasing some false trails it seems (big surprise). So, ignore most of what I said above as it does not seem to apply.

                        Anyway, I think you nailed it. When the Graphic Scale is set to the same numbers as the width and height of the graphic control the problem presents itself (as you said ... a scale factor of 1 .. or should I say -1 for the X axis). Change either the x or y scale values and everything works happily..

                        Sorry for the wild chase. And thanks for bringing this up so that I (and others) can avoid it.

                        Last edited by Gerald Sutherland; 3 Sep 2008, 04:38 PM.


                        • #13
                          Originally posted by Gerald Sutherland
                          Sorry for the wild chase. And thanks for bringing this up so that I (and others) can avoid it.
                          Np. I wanted some fresh ideas and verification that I'm not doing something really stupid (with something that I have missed so far). Thank You for doing the verification work.

                          Of course the latter point was also in my mind, too.

                          cheers.. aSa C[_]