Announcement

Collapse

New Sub-Forum

In an effort to help make sure there are appropriate categories for topics of discussion that are happening, there is now a sub-forum for databases and database programming under Special Interest groups. Please direct questions, etc., about this topic to that sub-forum moving forward. Thank you.
See more
See less

Difference between 8.03 and 8.04 in Graphic Print

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Difference between 8.03 and 8.04 in Graphic Print

    I notice a little difference between PBWin 8.03 and 8.04.
    In the following program compiled with 8.04 when a string is printed char by char in a graphic using a fixed font (Courier)
    the final result is not the same as when printing the whole string at the same time.

    Code:
     
    #include "win32api.inc"
     
    
    Function PBMain() as long
    dialog new pixels,0,"Test",,,1000,500,%ws_caption or %ws_minimizebox or %ws_maximizebox or %ws_sysmenu,0 to hdlg&
    control add graphic,hdlg&,1001,"",0,0,980,450,%ws_border or %ws_clipsiblings,%ws_ex_clientedge
    graphic attach hdlg&,1001,redraw
    graphic font "Courier New",15,1
    x!=0!
    c$="MAMMA PROVA QUADRO" ' any string to print
    for c%=1 to len(c$)
    graphic set pos (x!,100!)
    graphic print mid$(c$,c%,1); ' print string char by char
    graphic redraw
    x!=x!+12! ' 12 is the size in pixel of any character in the selected fixed font
    next
    graphic set pos (0!,120!)
    graphic print c$; ' print whole string
    graphic redraw
    dialog show modal hdlg&
    control kill hdlg&,1001
    dialog end hdlg&
    End Function
    In the first case every char overwrite a small part of the previous one.
    This didn't happen in PBWin 8.03.
    Any idea about cause/workaround ?
    Thanks

    In the true program the string is an input field written char by char when the user input chars from keyboard.
    I workaround the problem rewriting the complete field after every keystroke,
    but this kind of problems leave me in doubt ... how many small, but annoying differences will I find ?

  • #2
    >x!=x!+12!

    This is not good.

    Measure the fixed font size once using the DrawText() API (DT_CALCRECT)
    Use (R.nRight - R.nLeft) for char offset.
    hellobasic

    Comment


    • #3
      I wrote that statement only to keep source simple.

      In real program I used graphic text size "X" to nwidth!, nheight!.
      nwidth! value IS exactly 12, so don't matter as you determine it, 12 is always 12 ...
      The problem happens even using "M" o "W" o "I" instead of "X" and even using other font size (in that case x! increment will be different, of course).

      The main question remains open; why it's ok in 8.03 and doesn't work in 8.04 ?

      PS. However I'll try using that API

      Comment


      • #4
        You should send this to PB support if you haven't done so ( support @ powerbasic . com Include your serial number.). Usually they'll see things here but not always.
        Politically incorrect signatures about immigration patriots are forbidden. Googling “immigration patriots” is forbidden. Thinking about Googling ... well, don’t even think about it.

        Comment


        • #5
          Originally posted by Claudio DalZovo View Post
          result is not the same as when printing the whole string at the same time.
          Funny part of that, this effect appear on modern hardware, but if you will run your example on something like Pentium-II, it work as expected.

          I afraid difference in FPU produce this behavior
          -=Alex=-

          Comment


          • #6
            I can not duplicate the problem here on an AMD XP2800, WinME system. All looks ok and measures ok. Later I might find time to try on 64bit CPU, XP system. However, if anyone can duplicate this on any "modern" hardware, it could be helpful to post the CPU and OS combinations.

            Also,
            In real program I used graphic text size "X" to nwidth!, nheight!.
            I believe you meant Graphic Chr Size. Graphic Text Size gives the "width" of the whole string.
            Rick Angell

            Comment


            • #7
              Claudio's code converted to PBCC:
              Code:
              Function PBMain
               Dim hdlg As Dword
               Dim x As Single
               Dim i As Long
               Dim s As String
               Graphic Window "", 0,0, 800,600 To hdlg
               Graphic Attach hdlg,0,ReDraw
               Graphic Font "Courier New",15,1
               s = "ANY STRING TO PRINT"
               x = 0
               For i = 1 To Len(s)
                Graphic Set Pos (x,100)
                Graphic Print Chr$(Asc(s,i)); 'print string character by character
                Graphic ReDraw
                x = x + 12                   '+ size in pixels of a character in Courier New
               Next
               Graphic Set Pos (0,120)
               Graphic Print s               'print the whole string at once
               Graphic ReDraw
               Sleep 3000
              End Function
              I see no difference running under Windows 98se on a Dell Pentium III.
              Last edited by Mark Hunter; 25 Oct 2007, 10:43 AM.
              Politically incorrect signatures about immigration patriots are forbidden. Googling “immigration patriots” is forbidden. Thinking about Googling ... well, don’t even think about it.

              Comment


              • #8
                I ran both Claudio's and Mark's programs.
                It appeared as though Claudio's program showed the artifact and
                that Mark's program did not. Then I observed that the two programs
                were not printing the same strings. For the string:

                Code:
                    c$="ANY STRING TO PRINT"  ' any string to print
                both programs produce the same result, i.e. the artifact was not present.

                Then, for the string:

                Code:
                    c$="MAMMA PROVA QUADRO" ' any string to print
                both programs did show the same artifact.

                My conclusion: Powerbasic does not speak Italian!

                I used the following platforms:
                Code:
                 
                PB/CC Ide Version 4.04.0042
                PB/WIN Ide Version 8.04.0042
                 
                System:
                      Microsoft Windows XP
                      Professional
                      Version 2002
                      Service Pack 2
                 
                Manufactured and supported by:
                      IBM Corporation
                      IBM Thinkpad
                      Intel Pentium II processor
                      365 MHz. 256 MB of RAM
                Last edited by Robert DeBolt; 25 Oct 2007, 11:52 PM.
                Regards,
                Bob

                Comment


                • #9
                  Copying Claudio's code (first post) compiles but doesn't show anything. Just sits there in memory and I have to use Task Mgr to close it. I guess it doesn't speak with a Jersey accent either {grin}.
                  It's a pretty day. I hope you enjoy it.

                  Gösta

                  JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
                  LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

                  Comment


                  • #10
                    I tried Claudio's and Mark's and mine (extended and modified from Claudio's) ... no artifacts when programs are run. Looks like a hardware thing to me. Makes no difference for the string used here.
                    Rick Angell

                    Comment


                    • #11
                      This has nothing to do with CPU's, FPU's, hardware, or the Italian language. <smile> It's an effect of over-aggressive kerning by WinXP.

                      We're looking into it to see if there may be some workaround. It's possible we'll be forced to just reduce the quality level of text drawing so they'll play by the correct rules. We'll see.

                      Thanks!

                      Bob Zale
                      PowerBASIC Inc.

                      Comment


                      • #12
                        Thanks Bob!
                        Remember the problem is not present in program compiled with PBWin 8.03 on the same PC.
                        I'll try on other hardware and Windows version, just to see ...
                        However problem has a low priority for me ... my workaround (rewrite the whole string after each kbd input) works well.

                        Comment


                        • #13
                          Originally posted by Gösta H. Lovgren-2 View Post
                          Copying Claudio's code (first post) compiles but doesn't show anything. Just sits there in memory and I have to use Task Mgr to close it. I guess it doesn't speak with a Jersey accent either {grin}.
                          It seems here in NJ, one can't use Pixels wider than the screen.

                          Removing Pixels from the Dialog New OR changing 1000 to 500 for the width and it runs fine. (I use an 800x600 screen). (For the record, I did rtm and din't seen nothin regarding this.)

                          It prints the two lines fine (even in Italian) and I can see what Claudio means (some chars overlap a little in the first line).
                          Last edited by Gösta H. Lovgren-2; 26 Oct 2007, 09:46 PM. Reason: FTR RTFM
                          It's a pretty day. I hope you enjoy it.

                          Gösta

                          JWAM: (Quit Smoking): http://www.SwedesDock.com/smoking
                          LDN - A Miracle Drug: http://www.SwedesDock.com/LDN/

                          Comment

                          Working...
                          X