xsharp.eu

This is our VO code:
SELF:oNetClnt:SetFilter( StrEvaluate('MTYPE=="&cType"') )

This line wouldn't compile under X# with VO dialect, but this line does comppile:
SELF:oNetClnt:SetFilter( &('MTYPE=="&cType_OpenServers"') )

It took runtime error. I know I can fix it by changing to:
SELF:oNetClnt:SetFilter('MTYPE=="' + cType + '"')

We have several other lines that are more complicated. Is there a better way fix this in X#?

Thanks,

Boonnam

Boonnam,
What is cType here?
- a Local
- a MemVar/Private/Public
- a Database field ?

Robert

In VO, cType is MEMVAR, but since MEMVAR isn't supported under X#, I changed it to global. I know that this code, "SELF:oNetClnt:SetFilter('MTYPE=="' + cType + '"')" works, but we need to get this to work with scripting.

Thanks

Boonnam,

Automatic expansion of memvars inside strings with StrEvaluate is not supported by the Vulcan Runtime because Vulcan does not know memvars.
And it does not support this for globals as well, as far as I know.
If you open the Vulcan runtime with reflector you will see that the contents of the StrEvaluate function is empty. It returns the original string.
Most likely you have seen a warning for the Obsolete function (or did you disable these warnings?)

// VulcanRTFuncs.Functions
[Obsolete("'StrEvaluate()' is not supported", true)]
public static string StrEvaluate(string s)
{
return s;
}

We have planned to add support for StrEvaluate to our runtime.
For now the syntax you suggest is the only thing that works.

Robert

Yes I saw the warnings about MEMVAR. That's why I changed them to GLOBAL. Any idea when new runtime will be released? Thanks.

Boonnam,

The runtime is planned before christmas. At least the Vulcan compatible part.
I am not sure if we will succeed to also add Memvar support at the same time.
Memvar support also requires a change in the compiler: functions/methods that use memvars will get a special prologue and epilogue code to declare the memvars in the symbol table and to release them from the symbol table when the function/method is finished.

Using memvars will therefore have a little overhead. Also because they are always of the type USUAL.

We cannot declare them as normal locals, since the visibility rules for memvars make them also visible from within code that is called by the code that declared the memvar.
And (of course) memvars will be of type USUAL just like in VO.

Robert

Sounds like memvars will make an app a lot slower than in VO.
I guess it is needed for a smooth transition from VO to .NET, but not very helpful further.

What I read in the help and Programmers Guide about memvars I don't see why I would want it in my programs in VO, and now especially not anymore in .NET.

Isn't it possible to device a tool to 'convert' the memvar 'automatically' to another concept?

Otto,

I do not think it will make apps a lot slower. Maybe somewhat slower but not a lot.
The compiler can detect if a method/function uses memvars
When it does it will introduce a (compiler generated) local that remembers the top of the memvar stack at the start of the function/method
And at the end of the function it will clear all memvars that have been added based on the value of this local.
The memvar itself is simply a symbol/usual pair.


Robert

Hi Otto,

in some macro evaluation engines memvars are very helpful - I'm using them in my report engine. And this was the main cause why I have not ported that one to Vulcan or X#.

Wolfgang

Not to mention that maybe it's a good idea to introduce a compiler option to allow MEMVARs or not, like there's an option for allowing late bound calls etc. So when that option is off, there should be zero performance decrease.

Chris