erratic behavior--Help!

[Steve Hutchesson]

Hi Ellen,

I am a fan of PBCC and its where I do most of my algorithm development as its all grunt without the need for much interface. I used PBCC 4 back when it was current but there are some real advantages in using the current version as it can do more and it can handle far larger amounts of data. Over time you will see the virtue of being able to create Windows user interfaces and with the DDT techniques in PBWIN there is a decent technique for doing that.

Effectively the sky is the limit in Win32 as you can if you had the need learn how to use the OS based API interface and you can even write assembler code if you need to. You don't have to but its there if you want it.

[Rod Macia]

Stuart, I may try PBWIN after I get through PBCC 6. I have installed it and am working through debugging. Almost no problems so far ... until this: I print a lovely double line box with dividers that contain invoice data in PBCC4.

DATA 2 , 33 , "BROWSE DATAFILE"

DATA 4 , 1 , " Co# Item Style Part Pt # Price"
DATA 5 , 1 , "ÉÍÍÍÍÑÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍ»"
DATA 6 , 1 , "º ³ ³ ³ ³ ³ º"
DATA 7 , 1 , "ÈÍÍÍÍÏÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍͼ"
DATA 9 , 4 , "CFR Price? Y/N Construction Code: Ref.Date:"

In PBCC6 the same lines print the characters as shown rather than the lines. How do I get my lines back?

probably using a different code-page in PBCC4

try putting
UCODEPAGE 437
at begining of program.
437 is IBM codepage.

[Ellen Reddick]

Thank you!!!! Works perfectly now.

[Dave Biggs]

- Rod was quicker

Hi Ellen,

PBCC6 supports unicode. The compiler translates between ANSI and UNICODE strings transparently.
The default CodePage used for these translations is ANSI - which doesn't readily support line drawing.

Best solution to support 'legacy code' is to specify the use of an OEM CodePage with the statement UCODEPAGE OEM as in this version of your posted code..

#Compile Exe        ' PBCC60
#Dim All
#If %Def(%PB_CC32)
 #Console On
 #Break On
#EndIf
#Include "win32api.inc"
'------------------/

Function PBMain () As Long
 Local sTemp As String
  Con.Color 10, -1 : ? "This System's code pages: OemCodePage =" + str$(GetOEMCP()) + " , " ;
  ? " AnsiCodePage =" + Str$(GetACP())
  Con.Color 7,  -1 : ? "Using UCODEPAGE OEM :" ;
  UcodePage OEM

  sDATA 2 , 33 , "BROWSE DATAFILE"

  sDATA 4 , 1 , " Co#   Item      Style                  Part                   Pt #     Price"
  sDATA 5 , 1 , "ÉÍÍÍÍÑÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍ»"
  sDATA 6 , 1 , "º    ³         ³                      ³                      ³        ³        º"
  sDATA 7 , 1 , "ÈÍÍÍÍÏÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍͼ"
  sDATA 9 , 4  , "CFR Price? Y/N            Construction Code:            Ref.Date:"

 StdOut sTemp + $CRLF + "Done"

 ? "Any key to exit"
    WaitKey$
End Function
'------------------/PBMain

SUB sData(x As long, y As Long, sText As String)
  'Locate x, y
  Con.cell x, y

  'Print sText
  Con.Print sText

End Sub
'------------------/sData

[Rod Macia]

Just an extra note regarding
UcodePage OEM
The OEM is dependent on the Windows installation language/region. and because of that it may not display as expected
So on my machine OEM = 850 Latin1
on a Japanese machine it would be OEM = 932
so its probably safer to use the 437

Try putting 850 or 932 on Dave's code and see what happens.

[Stuart McLachlan]

probably using a different code-page in PBCC4

try putting
UCODEPAGE 437
at begining of program.
437 is IBM codepage.

Or UCODEPAGE OEM for clarity

[Rod Macia]

Or UCODEPAGE OEM for clarity

did you read my post #25
UCODEPAGE OEM will not always give 437, it will change based on installed language/region.

on my system UCODEPAGE OEM give me 850 and therefore does not show correctly.

[Stuart McLachlan]

-
PBCC6 supports unicode. The compiler translates between ANSI and UNICODE strings transparently.
The default CodePage used for these translations is ANSI - which doesn't readily support line drawing.

Not quite accurate. There is no such things as "ANSI CodePage". ANSI uses CodePages.

PB will use whatever CodePage is set as the default for your computer. unless you change it with UCODEPAGE either to OEM (which is a synonym for Codepage 437) or to a specific numbered page. Ellen's computer is probably using 1252 as the default (aka Windows-1252).

Also you can change it at any point in your application, even in a function so the compiler can't tell what page will be needed It's not the compiler that makes the change it's the runtime.

'

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
    LOCAL s AS STRING
    s = CHR$(203)
    ? s
    changepage(1)
   ? s
    changepage(0)
   ? s
    changepage(1)
   ? s
    changepage(0)
   ? s
    changepage(1)
   ? s
END FUNCTION

SUB changepage( cp AS LONG)
    LOCAL l AS LONG
    IF cp = 1 THEN
        UCODEPAGE OEM
    ELSE
        UCODEPAGE ANSI
    END IF
END SUB
'

(See UCODEPAGE in Help for a more comprehensive explanation).

[Stuart McLachlan]

did you read my post #25
UCODEPAGE OEM will not always give 437, it will change based on installed language/region.

on my system UCODEPAGE OEM give me 850 and therefore does not show correctly.

Sorry I didn't before I posted UCODEPAGE OEM

You are quire correct.

I (and Bob Zale when he wrote Help) was not thinking about internationalised OEM.
" However, if you are compiling a CONSOLE application which makes use of the high-order ANSI codes, CHR$(128) through CHR$(255) for line drawing and a few international characters, you should declare an OEM CodePage by placing UCODEPAGE OEM at the start of your MAIN function."

[Dale Yarker]

Might be useful -
https://docs.microsoft.com/en-us/win...-winnls-getacp
'

#compile exe
#dim all
#include "WinNLS.inc"

function pbmain () as long
  local CPNum as dword
  CPNum = GetACP
  ? CPNum
  waitkey$
end function '

Cheers,

[Stuart McLachlan]

Might be useful -
https://docs.microsoft.com/en-us/win...-winnls-getacp
'

#compile exe
#dim all
#include "WinNLS.inc"

function pbmain () as long
local CPNum as dword
CPNum = GetACP
? CPNum
waitkey$
end function '

Cheers,

And possibly more to the point in this instance, GetOEMCP()

[Dale Yarker]

And possibly more to the point in this instance, GetOEMCP()

Yes. And if the result is not 437, then you may have to use UCODEPAGE 437 for box drawing instead of UCODEPAGE OEM.

[Dale Yarker]

Or convert the box drawing to Unicode (UTF-16 in PB)
see

https://en.wikipedia.org/wiki/Box-drawing_character

[Michael Mattias]

With regard to the line-drawing into which this thread has moved...

PB/CC does support the PB proprietary graphics window (GRAPHIC WINDOW NEW) and all the associated drawing commands.

This would eliminate any operating system or code page vagaries associated with the use of the line-drawing characters.

The GRAPHICS commands are identical to those in the PB/Windows compiler so migration to that compiler would be really easy should you go that way.

That is, maybe it's time to tell your existing code it has served well and long, give it a gold watch, and let it retire to Florida in dignity..

[Ellen Reddick]

Wow! I really opened up a can of worms, didn't I. You guys are great and I have learned so much from you. Thank you. After I finish my detailed inspection of the imported old code (all of which is working great BTW), I may dip my toe into PB/Win. Guess I will have to look at the GRAPHIC WINDOW NEW--thanks Michael Mattias for the suggestion. At the moment, my wish list is an easy way to add a popup window for error messages.