Frank,
bServer Lib is missing....
Break only when Debugging
Break only when Debugging
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Break only when Debugging
You don't get Warning at F9?
EDIT -> your first sample.
EDIT -> your first sample.
Regards
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Karl
(on Win8.1/64, Xide32 2.20, X#2.20.0.3)
Break only when Debugging
Hi Frank,
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:
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.
Chris
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:
Code: Select all
FUNCTION Start() AS INT
TRY
// program code...
CATCH oException AS Exception
// Display exception
END TRY
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.
Chris
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
-
- Posts: 280
- Joined: Sat Dec 12, 2015 2:22 pm
- Location: Germany
Break only when Debugging
No, i get no error with <F9> CompileFFF wrote:You don't get Warning at F9?
EDIT -> your first sample.
-
- Posts: 280
- Joined: Sat Dec 12, 2015 2:22 pm
- Location: Germany
Break only when Debugging
Hi Chris,
try / catch block noting change
i sen d you a complete Sample
Frank
I have change back to Vulcan Runtime and there the code work without error.
try / catch block noting change
i sen d you a complete Sample
Frank
I have change back to Vulcan Runtime and there the code work without error.
Break only when Debugging
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...
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
Break only when Debugging
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!
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
Break only when Debugging
Hi Chris,
PMFJI,
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.
Wolfgang
PMFJI,
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.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Break only when Debugging
Hi Wolfgang,
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.
Chris
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.
Chris
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu