Just noticed something strange: I have a .cmd file to generate code from a project 1) I run the .cmd file and get a "gen" folder with all the code beneath it. 2) I copy that folder leaving the original as-is. 3) I run the .cmd file again (clear destination folder=0 BTW) so it updates "gen".

When I compare the "gen" and "Copy of gen" folders, I see two differences: The first is that the 'empty' line (it has tabs) following a "__LLBLGENPRO_USER_CODE_REGION_END" directive is completely removed. This isn't a big problem but is annoying when diffing folders as it makes it harder to find the changes.

The second is that "xxxDBSpecific.csproj" has a different namespace stored - this looks like a bug. The original was <RootNamespace>BPOSS.Entities.DatabaseSpecific</RootNamespace> but the newly generated file has <RootNamespace>BPOSS.Entities</RootNamespace>

Cheers Simon

Just noticed that overwriting from the GUI does exactly the same.

Cheers Simon

simmotech wrote:

Just noticed something strange: I have a .cmd file to generate code from a project 1) I run the .cmd file and get a "gen" folder with all the code beneath it. 2) I copy that folder leaving the original as-is. 3) I run the .cmd file again (clear destination folder=0 BTW) so it updates "gen".

When I compare the "gen" and "Copy of gen" folders, I see two differences: The first is that the 'empty' line (it has tabs) following a "__LLBLGENPRO_USER_CODE_REGION_END" directive is completely removed. This isn't a big problem but is annoying when diffing folders as it makes it harder to find the changes.

You mean that the end marker is removed as well?

The second is that "xxxDBSpecific.csproj" has a different namespace stored - this looks like a bug. The original was <RootNamespace>BPOSS.Entities.DatabaseSpecific</RootNamespace> but the newly generated file has <RootNamespace>BPOSS.Entities</RootNamespace> Cheers Simon

Could you post the .cmd file? Updating a csproj file doesn't affect the namespace (that code isn't ran), it only replaces the files in the files xml element.

Correction, it does set the namespace again, to the rootnamespace set in the project, which is the rootnamespace specified. That's indeed a bug. The original namespace is set through a parameter in the preset, this one is simply overwriting it with the root namespace specified, so no suffixes specified. Hmmm... that looks tough to fix...

Otis wrote:

You mean that the end marker is removed as well?

The End Marker is not removed, only the next line is removed (which originally had 3 tabs in it). Not to worry if it is a problem to change but would be nice.

Cheers Simon

simmotech wrote:

Otis wrote:

You mean that the end marker is removed as well?

The End Marker is not removed, only the next line is removed (which originally had 3 tabs in it). Not to worry if it is a problem to change but would be nice.

Cheers Simon

Hmm, it should see that line as a line between the markers and thus re-emit it in the output.

Not between the markers, but after. This is CommonEntityBase.cs:

Before:

<tab><tab>// __LLBLGENPRO_USER_CODE_REGION_START PrivateMembers <tab><tab>// __LLBLGENPRO_USER_CODE_REGION_END <tab><tab>

<tab><tab>#endregion

After:

<tab><tab>// __LLBLGENPRO_USER_CODE_REGION_START PrivateMembers <tab><tab>// __LLBLGENPRO_USER_CODE_REGION_END

<tab><tab>#endregion

Cheers Simon

Reproduced.

(EDIT) Using latest version and templates. Generating code for: Adapter VB.NET 2.0 Generating from the GUI.

If the generated file didn't already exist in the target folder, any __LLBLGENPRO_USER_CODE_REGION_END line in any generated code file has an extra white line after it. Which will be removed if code is re-generated and the file was already there.

Steps: 1- Generate the code into an empty folder -> White lines appear. 2- Delete a specific file and regenerate (eg. CustomerEntity.vb) -> White lines appear. 3- Leave the file in its place and regenerate -> White lines are removed.

A regexp finds the begin/end markers + contents between them and stores them in a dictionary. The NEXT line below the end marker isn't contained in these regions.

When the TEMPLATE contains a begin/end statement for a user code region, the handler checks if there's a matched region in the dictionary. IF so, it emits THAT (which contains begin/end markers) into the output. If NOT, it will simply skip the start statement and emit what's next.

The empty line you see initially is the line with the <[EndUserCodeRegion]> statement on it. The tabs you see are the tabs in front of the statement.

When there IS a region in the existing file (so you generate over an existing file) that statement is skipped, as it isn't necessary to process it, a snippet has been found so the interpreter skips its nonterminal pointer till the next non-terminal after the <[EndUserCodeRegion]> non-terminal. This thus makes it skip the tabs in front of <[EndUserCodeRegion]>.

It's not that easy to fix this, as those tabs belong to the 'text' block seen AFTER the <[UserCodeRegionStart]> statement. This block simply contains the 2 lines with the markers and the tabs in front of the <[EndUserCodeRegion]> statement, that's 1 single token (as it is left untouched, and thus it is seen as literal text to output).

Emitting two tabs is also not an option, because it sometimes should be 3, 1 or other number.

So what could fix it, is to place the <[EndUserCodeRegion]> statements directly behind the end marker and not on the next line. Another could be to append the regexp in the interpreter with a whitespace group which matches the whitespace after the endmarker. ( \s+ )

I'll try the whitespace regexp group. The move of the endstatement in all the templates is too much work for now.

(edit) \s+ matches too much, it grows the file... trying another. (edit) \r\n[ \t]* solves a lot except the ones which have a dangling tab or whitespace after the endusercoderegion statement. That whitespace is ending up in the initial file, then it matches the regexp, but it is emitted again AFTER the matched user code region as it belongs to the literal text FOLLOWING the <[EndUserCodeRegion]> statement.

i.o.w. the only real fix is to move the <[EndUserCodeRegion]> to right after the end marker, which is a lot of work and I won't do that now. I will file a bugreport for this though so it will be fixed in v3, which will have a different template system.

About the namespace problem: The initial template has place holders for the various elements. For example the dbspecific rootnamespace has: <RootNamespace><[RootNamespace]><[DbSpecificNamespaceSuffix]></RootNamespace>

The routine which UPDATES a vs.net project file doesn't have these placeholders to work with, so it can't replace anything with the optional suffix. The problem is only in the adapter db specific vs.net project file.

This requires restructuring of the projectfilecreator taskperformer as it needs to pass the template text to the alter routine. Postponed till v2.6

The namespace problem has been fixed in v2.6, where the rootnamespace isn't overwritten anymore with the set namespace when the cs/vbproj file already exists. It's pretty meaningless to overwrite this namespace when the file already exists, as it could mean a changed name (by the developer) is reset with a rootnamespace based name.