Announcement

**Steve Hutchesson** · 23 Jul 2020, 09:19 PM

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** · 23 Jul 2020, 09:26 PM

Originally posted by Ellen Reddick View Post

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.

Code:

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.

Attached Files

**Ellen Reddick** · 23 Jul 2020, 09:48 PM

Thank you!!!! Works perfectly now.

**Dave Biggs** · 23 Jul 2020, 10:04 PM

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

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** · 23 Jul 2020, 10:30 PM

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** · 23 Jul 2020, 11:02 PM

Originally posted by Rod Macia View Post

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** · 23 Jul 2020, 11:09 PM

Originally posted by Stuart McLachlan View Post

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.

Attached Files

**Stuart McLachlan** · 23 Jul 2020, 11:43 PM

Originally posted by Dave Biggs View Post

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

'

Code:

#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** · 23 Jul 2020, 11:56 PM

Originally posted by Rod Macia View Post

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** · 24 Jul 2020, 02:17 AM

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

Code:

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

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

Cheers,

**Stuart McLachlan** · 24 Jul 2020, 02:22 AM

Originally posted by Dale Yarker View Post

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

Code:

#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** · 24 Jul 2020, 03:14 AM

Originally posted by Stuart McLachlan View Post

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** · 24 Jul 2020, 03:21 AM

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

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

**Michael Mattias** · 24 Jul 2020, 10:32 AM

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** · 31 Jul 2020, 02:36 PM

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.

**Ellen Reddick** · 1 Sep 2020, 11:34 AM

One last question, I hope! It is somewhat of a change of topic but still part of my upgrade to PBCC 6 saga. Does my program compiled in PBCC 6 execute faster than the PBCC 4 version? Orders input into the program require labels to be printed on Zebra printers in the various plants. Suddenly, the Zebra fails to print some of the labels sent to it. The old program can successfully print all. The program code is the same for that function. The only variable I have been able to think of is the speed of the packets going to the Zebra. I have just put in sleep 3000 that occurs every 15 labels and one of the operators is using this new version as of today. Always hold my breath when I go live! Hate to bring 3 plants to a standstill. Next week all computers will be brand new and the server will also. I may have to put in more sleeps then.

**Walt Decker** · 1 Sep 2020, 02:47 PM

At the moment, my wish list is an easy way to add a popup window for error messages

In PBCC6 there are at least three you can to that.

1: switch pages
2: use a GRAPHIC WINDOW with a GRAPHIC WAITKEY to give your users a chance to see it
3: use the API programming to create a popup message

Possibly (don't remember if this is implimented) : Use TXT.NEW to display a window.

**Albert Richheimer** · 1 Sep 2020, 02:55 PM

Originally posted by Ellen Reddick View Post

One last question, I hope! It is somewhat of a change of topic but still part of my upgrade to PBCC 6 saga. Does my program compiled in PBCC 6 execute faster than the PBCC 4 version? Orders input into the program require labels to be printed on Zebra printers in the various plants. Suddenly, the Zebra fails to print some of the labels sent to it. The old program can successfully print all. The program code is the same for that function. The only variable I have been able to think of is the speed of the packets going to the Zebra. I have just put in sleep 3000 that occurs every 15 labels and one of the operators is using this new version as of today. Always hold my breath when I go live! Hate to bring 3 plants to a standstill. Next week all computers will be brand new and the server will also. I may have to put in more sleeps then.

This is not a matter of the programs execution speed. It seems that there is data lost on its way to the printer. This is mainly a matter of missing handshake between the program and the printing hardware. Inserting 3 seconds of waiting time is no solution. Just think of the paper out situation...

How is the the printout looking after some lables are lost? Any garbled data?

**Ellen Reddick** · 1 Sep 2020, 04:16 PM

Well, when I put in the sleep statements, it fixed the labels. No, there was no garbled data, just missing labels, although in every case, the last label was printed correctly. How do I correct a missing handshake? My current solution:

Code:

IF fifty& >= 15 THEN 'used to be 50
fifty& = 0
SLEEP 3000
XPRINT CLOSE
SLEEP 1000
XPRINT ATTACH zPrinter

**Michael Mattias** · 2 Sep 2020, 10:18 AM

One last question, I hope! It is somewhat of a change of topic but still part of my upgrade to PBCC 6 saga. Does my program compiled in PBCC 6 execute faster than the PBCC 4 version?

Unlikely, unless the release notes ("History.txt") indicate "technical improvements" to a particular verb, function or statement.

Regardless, most of your program's performance is determined by YOU using your design and programming techniques. Any change attributable to the compiler will be essentially 'nada.'

Announcement

erratic behavior--Help!

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment