in our application we use SalCompileAndEvaluate quite heavily and everything works like a charm.
Now I want to extract some logic and try to compile it as a .NET dll, because we want to use the logic behind and deploy it as a web service. To do so, I had to replace the "SalCompileAndEvaluate" with "SalNetCompileAndEvaluate", because Window Handles aren't allowed in a .NET dll build mode.
Now it looks like, as if SalNetCompileAndEvaluate behaves a little strange , or at least quite different to its WIN32 counterpart.
To be concrete, we use it for certain decisions. So the term "mnWholeAmount != 0" is used as expression for SalCompileAndEvaluate. It works in WIN32 Build Mode (even with SalNetCompileAndEvaluate()), but if we change the Build platform to .NET, a error message appears:
"Unable to evaluate expression: mnWholeAmount != 0 Interne Einschränkung im Compiler", The last sentence means something like "internal restiction in JIT Compiler".
Is that really the case? I cannot evaluate expressions in .NET which give a o or 1 as a result (somthing like what you would write in a if-statement).
In addition to that, every SAL* Function isn't supported, but thats at least written down in Help. But I have to think about how to get around that restriction as well. perhaps program the logic behind SalStrLeftX() and every other in C# and try to replace it dynamically or somewhat.
Anybody any ideas?
Regards and thx in advance for any hint,
Re your request for ideas, Holger, you might try the expression "If mnWholeAmount" -- since Booleans are Numbers 'under the covers' that might evaluate the same as your "mnWholeAmount != 0" statement, since both return TRUE when mnWholeAmount != 0.
In a quick test in v6.3 Win (not NET), both msg. boxes display for me:
Code: Select all
On SAM_AppStartup Set mnWholeAmount = 999 If mnWholeAmount != 0 Call SalMessageBox( '', '', 0 ) If mnWholeAmount Call SalMessageBox( '', '', 0 )
first of all, thx for your reply. Sorry for the typo in my translation above. The correct translation is:
The last sentence means something like "internal restriction in JIT Compiler".
But you got it right anyway .
Tried your recommendation and you're right, that works, thx for that . So, at least if we have only one variable to decide and if it is "0" to aks for, that would be a solution.
But often we have to make the decision on a specific value like "2", or depending on more than one value
mnWholeAmount AND mnCountTaxKeys > 1
- ( mnWholeAmount + mnPartialAmount ) = 2
It seems that all of that is not supported by the .NET Build Mode. Only one variable and only to aks for 0 or any other value
Anyway, thx for your recommendation, at least that's a little progress
Unfortunately, you are so right I wrote a test showing that SalNetCompileAndEvaluate() evals. OK in design mode but not in build mode as either an EXE or XBAP.It seems that all of that is not supported by the .NET Build Mode. Only one variable and only to aks for 0 or any other value
Not sure what to suggest next. Maybe provide us an example or 2 of how an expression like "mnWholeAmount AND mnCountTaxKeys > 1" is composed in your Win32 appl. to see what options might be available for rewriting it without the SalNetCompileAndEvaluate() call?
thank you for the offer.
We use SalCompileAndEvaluate() for quite complicated stuff. Unfortunately, it is the technological basis for our accounting module. Every customer has a different program (SAP, MS Dynamics, Datev,...) we have to integrate with. So we have a lot of very different looking APIs and technologies to interact with (some want files, other database links, others web services or RFC calls). Every financial program has its own layout and setting and field-names for the API, and on top of that every customer wants to see different values in these fields.
So we designed some kind of universal interface where we can dynamically create database tables based on a schema we can provide and with SalCompileAndEvaluate( ) we can then fill the columns with specific values, which represent a single field of the API of that customer specific fincancial program.
But its always the same logic from our programs view. SalCompileAndEvaluate does then the magic to fullfill the different requirements (where should the values come from, where are they stored) we have. We do quite complicated stuff in there (Whole database selects and so on).
Sorry, its quite difficult for me to describe that in english, I hope you understand what I mean .
So I think it would be very difficult for this forum to help us with that, because of the design of the whole program.
We opened a bug report (#TD-23902), so perhaps Opentext looks at least about that "mnWholeAmount" vs "mnWholeAmount != 0" thing.
Have a nice weekend and greetings from Oberkirch,
Your English is great BTW and I understand what you wrote. SalCAE is very useful for dynamic ('on-the-fly') statement creation. If you would, be sure to keep us aware with an update to this forum thread about any changes and/or fix to TD-23902. Even a simple Boolean eval. of an expression with > 1 component should be allowed. TIA.
to keep you up to date, OpenText closed the original ticket (#23902). But that was somewhat a misunderstanding, so there is a new Bug Number (#TD-23979) for this case.
Didnt hear something about it since mid of March.
I got another idea, but I don't thinks its possible.
Does anybody know if there is the chance to build a normal WIN32 DLL in centura, to which I can then talk to via Interop from .NET?
This way I could use the WIN32 SalCompileAndEvaluate and the .NET functions parallel.
Either way, I keep you informed, as soon as I know something new.
we received an update to our ticket:
Your ticket has been closed. We hope we've addressed your issue to your satisfaction.
Below is some information related to your ticket resolution:
Currently, in TD .NET there is no support for equality expressions, the request here is for implementing such support.
An Enhancement Request has been submitted to Product Management for review of this request.
Well, without the possibility to even check equality expression SalNetCompileAndEvaluate is simply useless for us. Our satisfaction regarding this point is somewhat limited, like the functionality of SalnetCompileAndEvaluate
A little bit sad, I really hoped this could be changing.
Who is online
Users browsing this forum: No registered users and 1 guest