Code-Formatter PB 10

[Peter Weis]

Hi Paul,

See my posts #52 & #54.  I had tried the code there but it didn't get executed.
Plus the code you put there doesn't match what Phoenix says should be there.
So I removed the excess code.

The code is not superfluous, he is bulged whom a file is passed in the command. Then the dialogue should not be executed

Still more strangeness.
In the InitApplication,
if %UNICODE is defined you get the command line but the program then ends right there.
if %UNICODE NOT defined  you get only the 1st char & file not found & program ends.

You currently do not you allowed to use Unicode, since Phoenix is not able to cope. Only when the program is fully programmed. Then strings are XSTRING, and all through ASCIZ XASCIZ functions replaced in Phoenix, then it goes again

In CopyBak doing a date/time stamp you don't allow for "/" in date. Also the program ends
after making the copy.

'll Try that again yesterday, it has gone


regards Peter

[Paul Elliott]

Peter,

Have you tested getting a command line? The routine as written isn't right for ASCII data.
Some comments as to why that extra code was in there would have helped.

What does Phoenix have to do with this? This is PB code and should be UNICODE safe.
I thought you handled the ASCII/UNICODE parts with your macros?
Or will you have to wait for Phoenix v3 before the program will work?

Just curious as I keep hitting a brick wall on getting things to work.
It's time to quit for the nite ( been up since 3am ). Be back sometime tomorrow.

[Peter Weis]

Hi Paul,
you do not have to wait until 3.0 comes out of Phoenix, just until I'm finished with the IDE, then I write about the parameters. One can then no longer go with Phoenix tuned!

regards Peter

[Dominic Mitchell]

Phoenix 2.0 does not support unicode.
Phoenix 3.0 does.

[Peter Weis]

Hi Dominic,

I know that Phoenix does not support Unicode 2.0. Hold me, but with macros but above water and then go Unicode!

regards Peter

[Peter Weis]

Hi Paul,
I changed the variables in CodeFormatter_InitApplication type so that command goes!
Command is always the case PowerBASIC 10 WSTRINGZ PTR

Code Select Expand


FUNCTION CodeFormatter_InitApplication _
  ( _
  BYVAL hInstance AS DWORD, _ ' handle of current instance
  BYVAL lParam    AS LONG _   ' address of command line
  ) AS LONG

  LOCAL lpszcmdline AS WSTRINGZ PTR                     '20.11.2011 Muss Bei PowerBasic 10 WStringz Ptr
  LOCAL filenum AS LONG
  LOCAL ztext , zOut AS XASCIZ * %MAX_PATH
  DIM Built AS GLOBAL IPOWERTIME

  LET Built = CLASS "PowerTime"

  Built.Now()

  REDIM tabhandle(0 TO 1)

  filenum = FREEFILE
  OPEN "Code Formatter.cfg" FOR BINARY AS filenum
  GET filenum,,fo
  CLOSE filenum

  lpszcmdline =  lParam

  'check the command line for a filespec
   IF LEN(@lpszcmdline) THEN
      IF ISFILE(@lpszcmdline) THEN
         fo.fspecin = @lpszcmdline               'assumes valid source file
         fo.fspecin = fo.fspecout
      ELSE
         MessageBox 0, "File not found" + $CR + @lpszcmdline, "", %MB_ICONINFORMATION
         FUNCTION = %TRUE
         EXIT FUNCTION
      END IF
   ELSE
     FUNCTION = %FALSE
     EXIT FUNCTION
   END IF

   CopyBak

   GetTempPath %MAX_PATH, ztext
   GetTempFileName ztext, "fmt", 0, zOut ' 11/18/2011 fo.fspecout
   fc.fhin = FREEFILE
   OPEN fo.fspecin FOR INPUT ACCESS READ AS fc.fhin
   fc.fhout = FREEFILE
   OPEN zOut FOR OUTPUT AS fc.fhout
   '~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   'Create a simple progress control
   '~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   fc.hprogress = CaptionProgressWindow(0, "Format Source Code")
   DoFormat
   CLOSE fc.fhin, fc.fhout
   DestroyWindow fc.hprogress
   CopyFile zOut, fo.fspecout, 0
   KILL zOut
   FUNCTION = %TRUE
END FUNCTION
     



I also have a call to Form1_Btn_Format_Clicked GetOVars () are inserted so that the data is transferred from the Options fields

Code Select Expand


FUNCTION Form1_Btn_Format_Clicked _
  ( _
  BYVAL hWndParent  AS DWORD, _ ' handle of parent window
  BYVAL hWndCtrl    AS DWORD _  ' handle of control
  ) AS LONG

  LOCAL ztext AS XASCIZ * %MAX_PATH
  LOCAL zOut AS XASCIZ * %MAX_PATH
  LOCAL tmpFC AS fmtcommon
   GetOVars()  ' Get Contol vars 11/20/2011
   fc = tmpFC ' re-initialize all variables 11/18/2011

   CopyBak

   GetTempPath %MAX_PATH, ztext
   GetTempFileName ztext, "fmt", 0, zOut ' 11/18/2011 fo.fspecout
   fc.fhin = FREEFILE
   OPEN fo.fspecin FOR INPUT ACCESS READ AS fc.fhin
   fc.fhout = FREEFILE
   OPEN zOut FOR OUTPUT AS fc.fhout
   '~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   'Create a simple progress control
   '~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   fc.hprogress = CaptionProgressWindow(0, "Format Source Code")
   DoFormat
   CLOSE fc.fhin, fc.fhout
   DestroyWindow fc.hprogress
   CopyFile zOut, fo.fspecout, 0
   KILL zOut

END FUNCTION       


regards Peter

[Paul Elliott]

Peter,

Do you see anything wrong with your code below?

Code Select Expand


  IF LEN(@lpszcmdline) THEN
      IF ISFILE(@lpszcmdline) THEN
         fo.fspecin = @lpszcmdline               'assumes valid source file
         fo.fspecin = fo.fspecout
      ELSE



For whatever work I do  I'm adding #OPTION ANSIAPI and commenting %UNICODE = 1.

Frankly for general user maintenance  it would have been better to go with DDT or plain SDK.
At least anybody who might want to make changes would have all the tools needed.

[Peter Weis]

Hi Paul,
must be of course different. How could this happen to me
must of course be like this!
I have not noticed during testing because the old one was sailed in fo.fspecout stores.
Mus course so hot

Code Select Expand


IF ISFILE(@lpszcmdline) THEN
         fo.fspecin = @lpszcmdline               'assumes valid source file
         fo.fspecout = fo.fspecin
      ELSE


Thank you Paul

[Peter Weis]

Hi Paul,

Frankly for general user maintenance  it would have been better to go with DDT or plain SDK.
At least anybody who might want to make changes would have all the tools needed.

Perhaps it would have been better! But now Phoenix makes even the best code. And you have to make changes to only once at the end who I am done with the IDE

regards Peter

[Paul Elliott]

Does the commandline version force a backup? Or a date/time stamp backup?
Or does it risk overwriting a good backup produced by another program?

Maybe but the next revision to the GUI can't even be done in Phoenix according to what
you're saying. It will either have to be changed manually or ( more likely ) all ripped out and
started from scratch.

Why can't the SDK code produced by Phoenix handle UNICODE? I was under the impression
that PB is supposed to handle the conversion UNICODE <-> ANSI transparently to the
programmer.

[Dominic Mitchell]

The code Phoenix 2.0 generates is ANSI.
However, the code can be changed to unicode with the following modifications:

1. Define the unicode constant at this location.

Code Select Expand


' >>PHNX_END_OPTIONS

%UNICODE = 1

' >>PHNX_BEGIN_WINAPI


2. Replace All(Whole Word, Current Project) ASCIIZ to WSTRINGZ
3. Replace All(Whole Word, Current Project) STRING to WSTRING
4. If Tooltips control is used, Replace All(Whole Word, Current Project) %TTN_GETDISPINFO to %TTN_GETDISPINFOW

Steps 2, 3 and 4 will have to be done after every build.

[Peter Weis]

Hi Paul,

Does the commandline version force a backup? Or a date/time stamp backup?
Or does it risk overwriting a good backup produced by another program?

You need to make you not worry because the program makes a backup with time stamp, whom it is set in the options so! You put the program to the desktop, and drag the file you formatierst via drag and drop on the code format.

Maybe but the next revision to the GUI can't even be done in Phoenix according to what
you're saying. It will either have to be changed manually or ( more likely ) all ripped out and
started from scratch.

You need only few strings through XSTRING and ASCIZ XASCIZ by replacing the only concerns the functions WinMain CodeFormatter_RegisterClasses, Form1_WndProc. The way I see it are the only three variables

Why can't the SDK code produced by Phoenix handle UNICODE? I was under the impression
that PB is supposed to handle the conversion UNICODE <-> ANSI transparently to the
programmer.

So who then is true Unicode and Unicode functions are called. Phoenix writes:

Code Select Expand


FUNCTION WinMain _
  ( _
  BYVAL hInstance     AS DWORD, _       ' handle of current instance
  BYVAL hPrevInstance AS DWORD, _       ' handle of previous instance(not used in Win32)
  BYVAL pszCmdLine    AS ASCIIZ PTR, _  ' address of command line
  BYVAL nCmdShow      AS LONG _         ' show state of window
  ) AS LONG


pszCmdLine is no ASCIZ PTR PTR but a WSTRINGZ PTR


But most times you go with the program debugger you that you see the place where the program gets out!

regards Peter

[Peter Weis]

Hi Dominic
What did you write that does not work, you can not replace all the strings by wstring, the source of the format, I still want to ANSI. You have to select exactly what is and what string wstring. You can do so only time you'll try to get hieroglyphics!

Also annoying is the produce after each of the source code to find out the places that need to be changed!
Dominic is it so hard to change these views of yours? Am also pleased with Phoenix 2.0

regards Peter

[Dominic Mitchell]

In the case of ANSI unicode mix, the replace needs to be done only on the *.bas
and Utility.inc files generated by Phoenix.
Where can I find the files for the Code Formatter? I would like to have a look at the
location of your code relative to that generated by Phoenix.

[Peter Weis]

Hallo Dominic

Here again, the code for you to put Unicode one and you will have your problems

regards Peter