Code-Formatter PB 10

[Paul Elliott]

Peter,

Got curious output from your last version. Sources & output attached.
Tabs in input.

o1 - no Insert Blank  no Replace _

o2 - no Insert Blank   yes Replace _

o3 - yes Insert Blank  yes Replace _

o4 - also checked your last option and got slightly different from o3

Am I doing something wrong? A little explanation for Insert Blanks & Replace _ would help.

I am not growling or yelling. Just asking.

[Peter Weis]

Hello Paul,

is straight again to it at working. We go through times point by point!

First is correct!


Option insert Blank is Off, Repace Underline is Off

input

Code Select Expand


local a, b, c _
d, e, f as long


outut:

Code Select Expand


local    a, _
         b, _
         c, _
d, e, f as long



Not beautifully however correct is one could

it in such a way make with variables according to option

Code Select Expand


local    a, _
          b, _
          c, _
          d, _
          e, _
          f _
          as long



Are straight at working the whole with AS or with underlined to replace 

I will piece by piece process the other points!

Greet Peter

[Paul Elliott]

Peter,

I must have not understood your reply to  Plamen Chobanov.

There was something about leaving the tab characters in the output lines.
The last version you posted didn't leave the tab characters in any formatted line.

What is the purpose of the 2 new options dealing with tab spaces?
Is this something that is not quite ready?

Again, I'm not growling or yelling. I just do not understand.

[Peter Weis]

Hallo Paul,

There was something about leaving the tab characters in the output lines.
The last version you posted didn't leave the tab characters in any formatted line.

What is the purpose of the 2 new options dealing with tab spaces?

All Tabs with blanks in the spring become code replaces!

That works!

Greetings Peter

[Paul Elliott]

Sorry but I did not understand that answer.

I'll wait for the final version to see what is being done.

[Paul Elliott]

no use posting as it is ignored.

[Peter Weis]

Hi Paul,
I am not come to this week to program something. Try it then it will find out what it is! 
regards Peter

[Paul Elliott]

no use posting this.

[Paul Elliott]

no use posting.

[Paul Elliott]

Rats!

Seems that no matter what I do or post, someone gets offended and there go my karma points.

[Peter Weis]

Hello Paul,

I have not taken points from you!!!

[Peter Weis]

Hello

A small update to version 2

I removed bug with # ELSE!

The progressbar I finally put in the status bar!

Also, I put in a DoFormat SLL or DLL

In version 3 I'm working on a completely redesigned format!

As you shall see what. And should test it, I published the source code again!

regards Peter

[Paul Elliott]

I refuse to reply as I've only got 1 karma point left.

Come on.

Hasn't anybody else looked at this? 

Seems that 5 people downloaded it.

[Paul Elliott]

Oh well.  So someone gets ticked at me ( again ).

Peter,
A couple hints to make things go easier.
1) move all Global numeric variables into the fmtcommon UDT.
2) move all Static numeric/string variables into the fmtcommon UDT.
unless they are really needed in the procedure for one-time-only processing that is not
affected by repeated calls to the DoFormat routines.

These 2 changes will enable you to reset all the variables at the beginning of DoFormat
procedure. No chance of any variable left with a value from a previous pass.
You will need to pass the fmtcommon UDT to DoFormat. Update both the fmtoption
and fmtcommon that were passed when leaving DoFormat if using the SLL/DLL version.

3) move the open/closing/backup/copying of processed files into the DoFormat procedure.
saves headaches when file numbers are not shareable between main EXE & SLL & DLL
via FreeFile.

4) create 3 procedures in your main BAS program for dealing with the progress bar.
Something like Show_ProgressBar, Update_ProgressBar, & Hide_ProgressBar.
Don't forget that you need to create a stand-alone progress bar if running with
a command-line file instead of from the GUI.

5) it might be easier to create a tiny program whose only purpose is to create the SLL/DLL.
It would only need a couple lines dealing with the compile and would include Doformat.inc.

6) move all the Macros down into DoFormat.inc. they are not needed in the GUI part of the
program.

See? Just a bunch of helpful hints. No screaming or yelling ( from my end ).

Peace!

[Peter Weis]

Hello Paul,

A couple hints to make things go easier.
1) move all Global numeric variables into the fmtcommon UDT.
2) move all Static numeric/string variables into the fmtcommon UDT.
unless they are really needed in the procedure for one-time-only processing that is not
affected by repeated calls to the DoFormat routines.

Because I'm just about to transfer all global variables to DoFormat!

These 2 changes will enable you to reset all the variables at the beginning of DoFormat
procedure. No chance of any variable left with a value from a previous pass.
You will need to pass the fmtcommon UDT to DoFormat. Update both the fmtoption
and fmtcommon that were passed when leaving DoFormat if using the SLL/DLL version.

You should watch it once before you write something. When calling DoFormat is passed to the UDT.

SUB DoFormat (BYREF fo fmtoptions AS)

move the open/closing/backup/copying of processed files into the DoFormat procedure.
saves headaches when file numbers are not shareable between main EXE & SLL & DLL
via FreeFile.

After, you want to program anything! But I want to program all alone, and in my work I have to go. It just takes a little time to be taken to file numbers from the main program! Also, I have not programmed.

) create 3 procedures in your main BAS program for dealing with the progress bar.
Something like Show_ProgressBar, Update_ProgressBar, & Hide_ProgressBar.
Don't forget that you need to create a stand-alone progress bar if running with
a command-line file instead of from the GUI.

Since I'm still working! The'll see how I do it!


And now I look just unbend a little bit of TV time for anything