Macrocompiler: error XM0101: Unexpected '<'

[FdeRaadt]

Hello everyone,

I have the following code:

Code: Select all

oColorCondition := bColorCondition{ cCondition, oColumn:server, oForeground, oBackground }

Which resuls in the following error:
Macrocompiler (1,97): error XM0101: Unexpected '<'

I've included the MacroCompiler.DLL and macroCompiler.full.DLL. Just in case have I included an screenshot of the stacktrace.
Why does it look like that the error happens in xSharp.DLL instead of my own code.
I would be very suprised if the root of the problem is indeed an incorrect DLL file.

Frank

[Chris]

Hi Frank,

If you scroll down the error dialog, you will see the place in your code where the error happened. The message just gives you the full information

About the problem itself, what are the contents of cCondition when the error happens?

.

[ic2]

Hello Chris,

Frank posted the errorline (in the text as code and in the picture).

Code: Select all

oColorCondition := bColorCondition{ cCondition, oColumn:server, oForeground, oBackground }

It's called many times, like this:

oBrowser:SetColorConditions(nDosKolom, "server:SomeField",KleurC(COLORred,1),NIL,TRUE)

Function Kleur returns in the end RGB(3 values) or a brush.

I've looked at this error too together with Frank but couldn't figure out what a macrocompiler error is doing in a bBrowser colorcondition statement. Also it works without any problem in VO.

We have never used the macro compiler for anything....

Dick

[Chris]

Hi Dick,

My guess is that the error happens when bBrowser tries to macro compile the macro supplied, through the cCondition argument. For this reason I asked what are the contents of this variable when the error happens.

.

[robert]

Dick,

We have never used the macro compiler for anything....

bBrowser uses the macro compiler to compile the conditions that you pass as string into a runtime codeblock.
My version of bBrowser has this code

Code: Select all

CONSTRUCTOR(uCondition, oServer, oForeground, oBackground) 
		// ======================================================================================
		// Beschreibung:	Objekt initialisieren.
		//
		// Historie:		06.09.2001	JB	Methode implementiert.
		// 					13.01.2010	JB	Argument RecNo in Codeblock implementiert.
		// ======================================================================================
		if IsString(uCondition)
			self:uCondition := &("{|Server, Column, Row, RecNo| " + uCondition + "}")
		else
			self:uCondition := uCondition
		endif
                 .
                 .
                 .
		return

The expression &(...) uses the macro compiler to generate a runtime codeblock
Robert

[ic2]

Hello Robert, Chris,

Thanks for the explanation, I didn't realize that the Macrocompiler was used in Colorconditions.

Today we found the cause thanks to your suggestion and that is quite interesting. The second parameter was:

Code: Select all

server:FIELDGET(#SomeField)>"0"  .and. server:FIELDGET(#SomeField))< Str(nAdmissionlevel,1,0)

As you may see (we saw it after a while) there's one closing bracket too many , you will see 2 instead of one after the 2nd #SomeField. That makes me wonder why VO did not crash there? I suspect that the color condition never worked there (that's next to check) but VO ignores it rather than crash like X#. Does this makes sense?

What I also wonder is why the error isn't something like unbalanced parenthesis? And also : is there any way a compiler could see that it is passing an unbalanced string (which is the above color condition)? I realize that a string is normally not further checked but I can imagine that when the string eventually will be passed to the Macrocompiler that it may be handy if the compiler could somehow detect that it won't work. Not sure if if and even less how I must admit.

Dick

[robert]

Dick,

The VO macro compiler is more forgiving than our macro compiler. It simply ignores the extra closing parenthesis.
Places where the macro compiler is used are:
- index expressions
- filters for workareas
- all places where you specify a string that needs to be evaluated, such as the cCondition in the bBrowser color condition

The compiler cannot know that you are passing the string to the macro compiler. you simply pass the string to the bColorcondition and whatever this component does with the string is not visible to the compiler.
Inside bColorcondition your string is converted to a codeblock like this:

Code: Select all

if IsString(uCondition)
   self:uCondition := &("{|Server, Column, Row, RecNo| " + uCondition + "}")
else
   self:uCondition := uCondition
endif

You can also use a "normal" codeblock here and then the compiler would warn you about the unbalanced parenthesis:
Btw: what is nAdmissionLevel inside the string? Is that a global or a public ?

Robert

[ic2]

Hello Robert,

The VO macro compiler is more forgiving than our macro compiler. It simply ignores the extra closing parenthesis.
Btw: what is nAdmissionLevel inside the string? Is that a global or a public ?

Then I personally prefer the more forgiving behavior of the VO macro compiler. As much as I appreciate the value of a tougher compiler warning for things which remained unnoticed by the VO compiler, a macro compiler that ignores redundant characters and still works is preferable above one which gives a runtime error on it IMO.

And yes, nAdmissionLevel is a global.

Dick