How about a WriteBlock function?

[JRL]

I do a lot of writing to file. Much of that is creating secondary scripts. The scripts are usually created by writing one line after another using the WriteLn> function, though I have occasionally used Concat> to create a long string that then gets written to file. Writing and maintaining these blocks of code becomes cumbersome as the secondary scripts become large.

I've been thinking it might be easier to read and edit these chunks of code if there were a WriteBlock> function. I see this structured similar to a subroutine structure where everything between WriteBlock>filename and EndBlock>filename gets written to "filename". It would be convenient if all of the editor code building functions worked within the WriteBlock> but it would also be helpful if the blocked code could be all one color, green for example, so that it can readily, visibly identified as WriteBlock> code.

For example:

Code: Select all

Let>incrementing_variable=0
Add>incrementing_variable,1

WriteLn>%temp_dir%myscript.scp,wres,Dialog>Dialog%incrementing_variable%
WriteLn>%temp_dir%myscript.scp,wres,   Caption=Dialog%incrementing_variable%
WriteLn>%temp_dir%myscript.scp,wres,   Width=445
WriteLn>%temp_dir%myscript.scp,wres,   Height=250
WriteLn>%temp_dir%myscript.scp,wres,   Top=101
WriteLn>%temp_dir%myscript.scp,wres,   Left=44
WriteLn>%temp_dir%myscript.scp,wres,   Button=OK,173,158,75,25,3
WriteLn>%temp_dir%myscript.scp,wres,EndDialog>Dialog%incrementing_variable%

WriteLn>%temp_dir%myscript.scp,wres,Show>Dialog%incrementing_variable%

becomes:

Code: Select all

Let>incrementing_variable=0
Add>incrementing_variable,1
WriteBlock>%temp_dir%myscript.scp,wres

Dialog>Dialog%incrementing_variable%
   Caption=Dialog%incrementing_variable%
   Width=445
   Height=250
   Top=101
   Left=44
   Button=OK,173,158,75,25,3
EndDialog>Dialog%incrementing_variable%

Show>Dialog%incrementing_variable%

EndBlock>%temp_dir%myscript.scp

[jpuziano]

I do a lot of writing to file. Much of that is creating secondary scripts. The scripts are usually created by writing one line after another using the WriteLn> function, though I have occasionally used Concat> to create a long string that then gets written to file. Writing and maintaining these blocks of code becomes cumbersome as the secondary scripts become large.

I don't write secondary scripts to a file from a main script too often (unless I am using one of JRL's creative "scripts that write scripts" workarounds...) however I do use multiple ConCat> lines to build up an SQL query string for later use in a DBExec> command.

I have to agree that when the number of ConCat> lines gets large, the process of maintaining these blocks of lines is indeed cumbersome.

I would love it if I could just paste the 20 new lines right in and be done with it... but at present, I too must edit one line at a time, being careful not to mess up the ConCat> at the beginning or the %CRLF% at the end of each line.

A few comments...

Please don't call it WriteBlock... maybe just Block... because we may not be using it with WriteLn>. It should be a generic construct.

Building on where JRL is going with this... if we make the additional leap to say that we want a fast easy way to assign a multi-line block to a variable, what we are really asking for is a fancy new way of defining a variable.

It is obvious we need to "blockend" as well as "blockstart" and the lines between are the content.

In terms of form, if we could imitate what is now used for defining a subroutine, that would be the cleanest. Here's an example of how it might look:

• BLOCK>My_Var,%CRLF%
  1st line
  2nd line
  any number of lines...
  ENDBLOCK>My_Var

So after the above lines ran, the variable My_Var will have been created and it will contain exactly the same characters as if it had been created with the following line:

• Let>My_Var=1st line%CRLF%2nd line%CRLF%any number of lines...

About the first line...

• BLOCK>My_Var,%CRLF%

The second parameter there might be an optional parameter... it is the delimiter to include between each line (or maybe at the end of each line... the last line is a special case). If left out entirely, it might just default to %CRLF%. Some folks might want to write files in UNIX format so they could include the parameter and just use %LF%. I can see applications where someone might also want to use %SPACE% or some other inter-line delimiter.

In any case, once created, this variable can just be used... in an ordinary WriteLn> command or in any command really... block line maintenance problem solved.

Also, I was thinking that including the variable name we are defining in the ENDBLOCK> line would be good... as it is more rigorous.

• BLOCK>My_Var,%CRLF%
  1st line
  2nd line
  any number of lines...
  ENDBLOCK>My_Var

For instance, this would allow the editor to be very strict and check that each BLOCK> statement has one and only one corresponding ENDBLOCK> statement. Anything less should (please) throw an error.

JRL would this serve your needs? Comments? Marcus, your thoughts?

I would be interested in hearing from anyone out there that maintains blocks of lines inside scripts as JRL has described... Now is the time... would this be useful to you?

Thanks for listening...

[Marcus Tettmar]

As it happens, something like this has already been implemented in dev for v12. It uses something that is already available: Data Labels. You know how when you import a file it creates a label like:

/*
MY.BMP_DATA:
bla bla bla
bla bla bla
bla bla bla
*/

Well, we've added a function called LabeltoVar. So at any point we can do:

LabelToVar>MY.BMP_DATA,newVarName

And, there's nothing to stop you making a label manually and putting whatever you like in a label:

/*
MYSTRING_STR:
Line One
Line Two
Line Three
Line Four
*/

LabelToVar>MYSTRING_STR,myStr

I hadn't thought of it being used like this, but it can be. So it probably meets all your needs already. I'll test it out and make sure.

[JRL]

This will work for me as long as there is the ability to pass variables to the block.

Let>var=FOUR
/*
MYSTRING_STR:
Line One
Line Two
Line Three
Line %var%
*/

[jpuziano]

Hi Marcus and JRL,

/*
MYSTRING_STR:
Line One
Line Two
Line Three
Line Four
*/

LabelToVar>MYSTRING_STR,myStr

Glad to hear this is coming... some questions below:

1) Placement - Does it matter where the Data Label block of lines occurs in the script? I am hoping it can be placed anywhere... and when execution comes to a line with a LabelToVar> command, it will just scan for the appropriate block and do its thing.

2) What will this use as an inter-line delimiter by default, %CRLF%? That may serve most purposes but it would be nice to be able to specify %LF% if we needed... or something else. How could we do that?

3) We might even want line prefixes or suffixes... instead of an interline delimiter... any way to specify that?

This will work for me as long as there is the ability to pass variables to the block.

Let>var=FOUR
/*
MYSTRING_STR:
Line One
Line Two
Line Three
Line %var%
*/

Thanks JRL, yes that would indeed make this more flexible. If we get this ability as well, further questions I'd have would be:

4) I would hope that the ONLY time a word in one of the Data Label block lines gets treated like a variable would be when that word is surrounded by percent signs as in %var% in the example above, true?

5) What happens if %var% is not yet assigned (i.e. does not even exist as a variable yet)... will it just show up as the literal text: %var% in the created variable?

6) Thinking of the things JRL likes to do... I'd imagine he'd like to control on a case by case basis... whether a LabelToVar> command substitutes in the value of %var% or just includes the literal characters %var%. I can see he'd also need the literal version in cases where the substitution is actually going to happen later, when the file he just wrote... runs as a separate marco later). The best place to control that would be from a parameter of the LabelToVar> command.

7) Messing with the existing VAREXPLICIT system variable to try to control this does not seem appropriate, that is for something else.

Here's a thought as to how almost anything could be accommodated:

LabelToVar>MYSTRING_STR,myStr[,variable_substitution[,inter_line_delimiter[,line_suffix[,line_prefix]]]]

MYSTRING_STR is the name of the Data Label block which can be placed anywhere in a script (hopefully).

myStr is the variable you are setting... its value will be set to contents of the named Data Label block.

Optional parameters below. Some have defaults which will be in effect even if you do not specify the parameter... just specify it to over-ride the default.

variable_substitution default is 1 which means all variable names surrounded by percent signs in the Data Label block lines will be replaced with the current values of those variables. You can set this to 0 to turn off variable substitution so for example... if you had %var% in one of your Data Label block lines, you would get the actual characters: %var% included in your myStr variable.

inter_line_delimiter default is %CRLF% so a carriage return and a linefeed character will appear between each Data Label block line inside your myStr variable. You could set this to %LF% for example or anything else desired.


line_suffix has no default. Specify this only if you want a certain character or characters added AFTER each line from your Data Label block lines, for example %CRLF%. Note that if you do this, you may also want to specify the inter_line_delimiter to be nothing... just have nothing between the appropriate commas, see below:

LabelToVar>MYSTRING_STR,myStr,1,,%CRLF%


line_prefix has no default. Specify this only if you want a certain character or characters added BEFORE each line from your Data Label block lines, for example %LF%. Note that if you do this, you may also want to specify the inter_line_delimiter and line_suffix to be nothing... just have nothing between the appropriate commas, see below:

LabelToVar>MYSTRING_STR,myStr,1,,,%LF%

Comments? Feedback?

Thanks for listening... and for the opportunity to throw these ideas out there.

[JRL]

Thanks JRL, yes that would indeed make this more flexible.

More Flexible? I think that for my original intent the ability to pass variables is mandatory. I can already embed a hardcoded script using several methods. I am looking for a block method to write dynamically created text to a file. That absolutely means that passing variables to the block is a necessity.

6) Thinking of the things JRL likes to do... I'd imagine he'd like to control on a case by case basis... whether a LabelToVar> command substitutes in the value of %var% or just includes the literal characters %var%. I can see he'd also need the literal version in cases where the substitution is actually going to happen later, when the file he just wrote... runs as a separate marco later). The best place to control that would be from a parameter of the LabelToVar> command.

I think I understand what you're saying here and I think I agree with all but the last line. But to be clear I'd like to restate this with examples.

If I write to a file that will be what I call a secondary script, sometimes I want %var% to be the value of the variable "var" written to the file and sometimes I want to write the text characters "%" "v" "a" "r" "%" to a file. Most of the time, within the same block, I'll want to do both. So I don't think I agree that "The best place to control that would be from a parameter of the LabelToVar> command." Unless I'm missing something, I don't think a parameter will give me infinite control over variables passed as values as opposed to percented variable text created in the file. I would prefer some way to escape an individual phrase.

For example.

Code: Select all

Let>var=FOUR

/*
MYSTRING_STR:
Line One
Line Two
Line Three
Line %var%
*/

LabelToVar>MYSTRING_STR,myStr
WriteLn>c:\file.scp,wres,myStr

Would create a file that looks like:

Code: Select all

Line One
Line Two
Line Three
Line FOUR

But something like:

Code: Select all

Let>var=Three

/*
MYSTRING_STR:
Line One
Line Two
Line %var%
Line [Text]%var%[/Text]
*/

LabelToVar>MYSTRING_STR,myStr
WriteLn>c:\file.scp,wres,myStr

Would write:

Code: Select all

Line One
Line Two
Line Three
Line %var%

I'm not suggesting syntax, only that some way to escape the text would be required.

[jpuziano]

Thanks JRL, yes that would indeed make this more flexible.

More Flexible? I think that for my original intent the ability to pass variables is mandatory. I can already embed a hardcoded script using several methods. I am looking for a block method to write dynamically created text to a file. That absolutely means that passing variables to the block is a necessity.

Sorry, I was just thinking from my own point of view here... as most of the stuff I do with large numbers of ConCat> lines wouldn't need this ability... but I can see for you its mandatory. Fair enough.

6) Thinking of the things JRL likes to do... I'd imagine he'd like to control on a case by case basis... whether a LabelToVar> command substitutes in the value of %var% or just includes the literal characters %var%. I can see he'd also need the literal version in cases where the substitution is actually going to happen later, when the file he just wrote... runs as a separate macro later). The best place to control that would be from a parameter of the LabelToVar> command.

I think I understand what you're saying here and I think I agree with all but the last line. But to be clear I'd like to restate this with examples.

If I write to a file that will be what I call a secondary script, sometimes I want %var% to be the value of the variable "var" written to the file and sometimes I want to write the text characters "%" "v" "a" "r" "%" to a file. Most of the time, within the same block, I'll want to do both. So I don't think I agree that "The best place to control that would be from a parameter of the LabelToVar> command." Unless I'm missing something, I don't think a parameter will give me infinite control over variables passed as values as opposed to percented variable text created in the file. I would prefer some way to escape an individual phrase.

True, the variable_substitution parameter I suggested only gives control over substitution in the whole block, all the lines, so for one LabelToVar> command, substitution can be either on or off.

You'd like infinite control - you want to have multiple variable placeholders on multiple lines and have some get substituted and some not.

If this ends up going the manual escaping route you suggest, it has already been stated that "editing these huge things is cumbersome" so instead of:

Line [Text]%var%[/Text]

I might suggest one of these two methods as they are less typing:

Line %%var%%
Line _%var%_

Or maybe some other succinct way to flag these that won't cause problems... Marcus will know what's safe.

But now back to parameters… Yes, I think parameters could give you the infinite control you seek… but we’d need another parameter.

For instance, in your last two suggested examples in your last post... to get those two different results, you had to use two separate and distinct Data Label blocks. Imagine the block is 100 lines long. To be able to produce both results from your main macro, you'd need to keep and maintain two separate copies of that code block, 200 lines.

What if there were more flavors where other variables were escaped and others not? More complete copies of the whole block.

I can see a way we could do with only one Data Label block (less code to maintain) and you could still have individual control over whether each variable was escaped when you used the LabelToVar> command. Here's an example:

Code: Select all

/*
MYSTRING_STR:
Line One
Line Two
Line Three
Line %var%
Line %var%
Line %var%
*/

Let>var=FOUR

LabelToVar>MYSTRING_STR,myStr
WriteLn>c:\file.scp,wres,myStr

The above Would create a file that looks like:

Line One
Line Two
Line Three
Line FOUR
Line FOUR
Line FOUR

Code: Select all

LabelToVar>MYSTRING_STR,myStr,1,,,1,3
WriteLn>c:\file.scp,wres,myStr

The above additional lines (no need for another code block) would create a file that looks like:

Line One
Line Two
Line Three
Line %var%
Line FOUR
Line %var%

The 1,3 is an extra parameter added on, let's call it the exception list. It would have to be the last parameter as it is just a list of variables to apply the opposite type of variable substitution to.

To clarify, the first 1 in the following line tells it variable substitution applies in general:

LabelToVar>MYSTRING_STR,myStr,1,,,1,3

The 1,3 is the list of variables to go against this rule... so it would escape the 1st and 3rd variables.

Conversely, if you had many variables and you wanted all of them escaped except the 25th and 26th, you could write this:

LabelToVar>MYSTRING_STR,myStr,0,,,25,26

This would truly reduce your manual editing of the one block... you only need the one block... and you would have full programmatic control over which particular variables you want escaped in a particular use of the LabelToVar> command.

Now let's get crazy (why not, we've gone this far). Lets say in your Data Label block, there are two variables that you use multiple times... and sometimes you want those two variables to be escaped... and sometimes you want substitution. If the command was really clever, it also might accept variable names in the exception list parameter.

The following could provide substitution in general with the exception of any variable named either var1 or var5:

LabelToVar>MYSTRING_STR,myStr,1,,,var1,var5

The opposite is easy to achieve by flipping the variable_substitution parameter. The line below would escape all variables except any variable named either var1 or var5:

LabelToVar>MYSTRING_STR,myStr,0,,,var1,var5

JRL... comments?

Marcus... sorry, just throwing ideas out there. This may be going overboard, but if its worth building, considering all options before building seems worth the time.

[jpuziano]

Here's some further thoughts.

If the color syntax highlighter colored percented vars and escaped-percented vars in the Block, that would sure make them easy to spot. Note: the red one is "escaped"... See below:

• /*
  MYSTRING_STR:
  Line One
  Line Two
  Line %var%
  Line _%var%_
  */

If the LabelToVar> command ends up not getting an exception list parameter, then I have one more idea to throw out there:

- we get manual escaping as you described JRL (whatever the characters end up being)

- we get a variable_substitution parameter, only the twist is, it could actually have four states:

0 - default if not specified, regular substitution - %vars% get substituted _%vars%_ get escaped
1 - flipped substitution - %vars% get escaped _%vars%_ get substituted
2 - forced substitution - both %vars% and _%vars%_ get substituted
3 - forced escaping - both %vars% and _%vars%_ get escaped

- I think we'd still need the inter_line_delimiter parameter if we're going to be able to write UNIX as well as Windows format text files:

[,inter_line_delimiter[,line_suffix[,line_prefix]]]]

- and the line_suffix and line_prefix parameters would allow full control over specifying delimiters though I concede these are a nice-to-have only

Thanks for listening...

[Bob Hansen]

I haven't had the chance to really read and digest all the details of the previous postings, but had a thought about the block variable concept also. This would be helpful when defining the Haystack for RegEx.

Because the script editor doesn't word wrap EndOfLines, I find that I am always creating an outside file and doing Let>HayStack=c:\temp.txt or something like that. But that means I cannot easily see or define the value of the Haystack. Being able to write a block with natural EndOfLines and making that into a variable would be another application of that concept.

[jpuziano]

Being able to write a block with natural EndOfLines and making that into a variable would be another application of that concept.

Hi Bob,

It sounds like a fit... but if you have time, could you please post a small/simple example showing the haystack, file and what the code does with them? Then we could see much better if this would be a benefit for you.

Thanks and take care

[Bob Hansen]

Normal multiple line entry in Macro Scheduler for Haystack looks like this, can be difficult to read in script and in WatchList:

Code: Select all

Let>vHaystack=line1%CRLF%line2%CRLF%line3%CRLF%line4%CRLF%line5%CRLF%line6%CRLF%line7%CRLF%......
Let<vNeedle=something
RegEx>%vNeedle%,%vHaystack%......

=============================
So, now I make a file that is easy to create/read in a text editor, C:\temp.txt that looks like this:
line1
line2
line3
line4
line5
line6
line7
.........

Now I can use that file in my script:

Code: Select all

ReadFile>c:\temp.txt,vHaystack
Let>vNeedle=something
RegEx>%vNeedle%,%vHaystack%.........

===============================
The Generic Block vs. WriteBlock is a good idea, more flexibility to use Block in any manner, Read/Write/Parse/RegEx/Copy/Paste,etc.

UseBlock syntax =
UseBlock>BlockName,variable
Block Line1
Block Line2
...
Block Line n
EndBlock>BlockName

The RegEx use of that UseBlock function would be like this:

Code: Select all

UseBlock>Block1,vHaystack
line1
line2
line3
line4
line5
line6
line7
.........
EndBlock>Block1

Let>vNeedle=something
RegEx>%vNeedle%,%vHaystack%.......

==========================================

Is that clear enough, or have I added confusion?


...
...
...

[jpuziano]

Hi Bob,

Thanks for posting that. Now that I see your example, yes it should be a help. You would no longer need the extra files where you now type in the Haystack lines... as you could type and maintain them in the main macro and... typing and maintaining it there will be easier because you won't have to manually type %CRLF% over and over again.

There's one point where I differ now though. Your suggested form was this:

Code: Select all

UseBlock>Block1,vHaystack
line1
line2
line3
line4
line5
line6
line7
.........
EndBlock>Block1

Let>vNeedle=something
RegEx>%vNeedle%,%vHaystack%.......

Yes, that was the original form I suggested... but after seeing what Marcus has done with Data Labels... I am now hoping for a form closer to this:

Code: Select all

Block>Block1
line1
line2
line3
EndBlock>Block1

BlockToVar>Block1,Haystack 

Let>vNeedle=something
RegEx>%vNeedle%,%vHaystack%.......

The difference is, we keep the definition of the block separate from the place where we load the block lines into a particular variable name. This gives us the ability to re-use that block in different ways without having to re-type the lines of the block.

For instance, if you also wanted to run another RegEx line further down but this time use a different variable name and inter-line delimiters, say %LF% instead of %CRLF%, you could just use this:

BlockToVar>Block1,Haystack2,%LF%

To me that's a lot better than having to retype the whole block.

Another thought just struck me. We could really get a lot of milage out of the default behaviour of a block definition. Consider this block:

Block>Block1
line1
line2
line3
EndBlock>Block1

At this point, there is no variable but the blockname is: Block1

Now further down in the script, we want to make use of this block. Let's say we want to write it to a file. So what if we just wrote this:

WriteLn>c:\file.scp,wres,Block1

Ahh you say it would fail because there is no VARIABLE yet called Block1.

True... but that doesn't have to be the case in the future. Default command behaviour could be changed such that after checking for a variable named Block1 (and finding none) it could additionally check for a blockname called Block1 and in this case, it would find it. It could then put the lines together in the default way and simply use them... In this case it would write them to disk to create the file.

The default way I am talking about is... using %CRLF% as inter-line delimiters.

Note that using it in this way does not create an actual variable called Block1... but we were still able to access and use Block1.

For any uses of Block1 other than in the default way, we would have to first use a command that loaded Block1 into a variable... because that command would have parameters allowing us to specify a different inter-line delimiter and whatever other parameters we'll have, for example...

BlockToVar>Block1,Haystack2,%LF%

...then we'd just use the variable Haystack2 in any command.

Again, just throwing these ideas out there. I would like to hear what the rest of you think.

Marcus, I have a question.

I created a file called "IMPORT_TEST.TXT" that contained 3 lines:

line 1
line 2
line 3

Then with my macro open in the editor, I clicked Tools/Import Binary File and pointed it at the file. This created the following lines in my macro:

/*
IMPORT_TEST.TXT_DATA:
6C696E6520310D0A6C696E6520320D0A6C696E6520330D0A
*/

So then I ran the following command...

ExportData>IMPORT_TEST.TXT_DATA,C:\Users\Owner\My Documents\export_test.txt

And sure enough it created a duplicate of the first file on disk named export_test.txt

So then I did this...

/*
I_TYPED_THESE_BLOCK_LINES.TXT_DATA:
line 10
line 20
line 30
*/
ExportData>I_TYPED_THESE_BLOCK_LINES.TXT_DATA,C:\Users\Owner\My Documents\export_test2.txt

And the file it created on disk was gibberish. I understand why... If I had typed the binary representation of the lines in my block, it would have written what I had wanted to write.

My question is... does your planned LabelToVar> command properly handle Data Labels where the content is binary AND where the content is ACII i.e. lines we have typed in directly?

If that is not possible or if it is problematic... then maybe Data Labels like this...

/*
IMPORT_TEST.TXT_DATA:
6C696E6520310D0A6C696E6520320D0A6C696E6520330D0A
*/

...should strictly be left to handle binary data and a new block definition structure like this...

Block>BlockName
Line 1
Line 2
Line 3
BlockEnd>BlockName

...could handle the ASCII format text.

Also, would BlockEnd> or EndBlock> be better to use? I suppose since we have VBEND... maybe BlockEnd> would be more in keeping with naming convention. In any case, I would caution against just using End> as that is what ends a subroutine.

Here's something else to ponder. What if we had the following lines:

Block>Block1
Line 1
Block>Block1
Line 2
Line 3
BlockEnd>Block1
Line 4
BlockEnd>Block1

In the above, the whole thing is Block1. Inside it, we merely have some lines that also define a block, maybe because this block contains code that will be another macro we write to disk. So would Macro Scheduler parse this correctly as one block named Block1? Or would we have to define it this way to help things along?

Block>Block1
Line 1
_%Block>Block1%_
Line 2
Line 3
_%BlockEnd>Block1%_
Line 4
BlockEnd>Block1

JRL, you like writing code that writes code, any thoughts? Marcus?

Again, just thinking out loud. Thanks for listening and take care.