copied your lines, then
FUNCTION Start( ) AS VOID
LOCAL uXSharpUsual AS USUAL
uXSharpUsual := "Hello X# runtime!"
LOCAL c AS STRING
LOCAL d AS DATE
Did you enable the option to break on "any exception". I can imagine that there is an exception inside the runtime (because we have not handled the empty date properly) but the result of the CTOD should still be a NULL_DATE. There is a TRY CATCH in the runtime that guarantees that the empty date is returned.
That would also explain why the code works "as expected" for Karl.
XSharp Development Team
i wrote i CAN DEBUG through all of the shown code. Make an X#runtime new app, copy my code in, set a breakpoint in the "today"line and Shift F5. Works or no?
There's no chance to verify problems, if there are no concise descriptions of what you are doing exactly...
Most probably it's what Robert said, it is a harmless exception that happens inside the rutnime code and is being properly handled by our code. Please check the caption of the dialog that is shown when the exception is intercepted, it says "<exception name> was handled" (not "unhandled"), right?
You can chose to not break on handled exceptions by using form the menu Debug/Unhandled Exceptions->Break Never. And yes, after so many years, I just now realized he caption of this menu item is incorrect
I think I see what you mean, that when you simply run the app, inside or outside the IDE, you do not get information about what caused the error. In order to get this information, surround all your code in Start() with a TRY...CATCH block:
FUNCTION Start() AS INT
// program code...
CATCH oException AS Exception
// Display exception
this way you will catch yourself an error when it happens in your program, exit gracefully and either display the error on screen (for example with System.Windows.Forms.MessageBox.Show(oException:ToString())), or save it in a log file etc. The Exception class gives you plenty tools to get info about what happened.
For the DataWindow with ArrayServer sample, with this method you should be able to see where the error is happening, But much easier while debugging the app, does not it tell you when and where the error happened? If it's hard to figure what's going on, please post a full zipped sample so we can have a look as well.
Guys, Frank has sent me a sample, the error that is occurring is being "eaten" by the code inside the SDK classes (in a BEGIN..END SEQUENCE), so it is being handled and a global TRY..CATCH will not catch it. We will probably need to do something about this and try to simulate VO's error reporting system to what extent is possible at least. Anyway, now let's have a look what causes the problem with the ArrayServer in the first place...
OK, found the problem, we have not implement the NoIVarPut() / NoIVarGet() functionality in the x# runtime and the ArrayServer code depends on this. Should not be difficult to implement, Frank will try to send you a fix for that asap, thanks for the report!
a functionality to get errors out of "begin-end sequence" constructs is absolutely needed.
In VO, it was perfectly legal and common to write such constructs without treating an error because the global errorblock catched the error - and my onw code contains tons of such code.
In Vulcan or X# such errors go lost, and I have searched several times to find out where my code failed in the X# version.
IMHO, there should be the possibility to set an error handler to some global variable in the runtime, and when translating "begin - end sequence" without "recover" statement, the compiler should insert a call to that error handler in the "catch" block.
Maybe something like that could help, but it will still be nowhere near what VO does. In VO, even if you have no BEGIN..END SEQUENCE statement at all, you can still trap errors in an error block and decide what you will do, if code will resume after the line that generated the error, if execution will stop, a message will be disaplyed etc etc. None of this is possible to do in .Net, the core runtime of VO was designed from the ground up to support something like that, while the .Net Framework runtime wasn't. Of course Robert can give more info on how the internals of VO work.
My thinking was to change the SDK code itself, to add more BEGIN..END SEQUENCE statements than are already used, in order to provide more "local" error handling, reporting and continuation of code execution as much as possible. Your suggestion could help as well, to help with reporting/logging of the errors. This needs some good thinking and investigation, maybe one of the first things to do once the x# runtime is fully done and debugged.