Difference between 8.03 and 8.04 in Graphic Print

[Claudio DalZovo]

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.

 
#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 ?

[Edwin Knoppert]

>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.

[Claudio DalZovo]

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

[Mark Hunter]

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.

[Aleksandr Dobrev]

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

[Richard Angell]

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.

[Mark Hunter]

Claudio's code converted to PBCC:

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.

[Robert DeBolt]

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:

    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:

    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:

 
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

[Gösta H. Lovgren-2]

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}.

[Richard Angell]

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.

[Bob Zale]

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.

[Claudio DalZovo]

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.

[Gösta H. Lovgren-2]

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).