Break only when Debugging

More
1 week 6 days ago #1 by Frank Müßner
Break only when Debugging was created by Frank Müßner
Hello,
I try some new code with X# without Vulcan DLL and have a Question.

I use XIDE 1.15 and X# Compiler version 2.0.0.6

this Code:

LOCAL c AS STRING
LOCAL d AS DATE

c:=DToC(today())
d:=CToD(" . . ")
d:=CToD(NULL_STRING)
d:=Null_date

I get no error when run start the Application. When Debug i get:

at this line:

d:=CToD(" . . ") --->>> System.FormatException Die Eingabezeichenfolge hat das falsche Format.

My Question is, why not show the Error when Run the App? Perhaps Settings in Xide?

Why CToD(" . . ") work with VO and not X#

Regards Frank

Please Log in or Create an account to join the conversation.

More
1 week 6 days ago - 1 week 6 days ago #2 by FFF
Replied by FFF on topic Break only when Debugging
Frank,
copied your lines, then
FUNCTION Start( ) AS VOID
LOCAL uXSharpUsual AS USUAL
uXSharpUsual := "Hello X# runtime!"
System.Console.WriteLine(AsString(uXSharpUsual))
LOCAL c AS STRING
LOCAL d AS DATE

c:=DToC(Today())
d:=CToD(" . . ")
d:=CToD(NULL_STRING)
? d:=Null_date
RETURN

Runs, as for you.
When debugging i have to switch to x86mode, then i can walk through all lines without a hitch.

Karl @W8.1/64, Xide 1.15 & X#2.0.0.6
Last edit: 1 week 6 days ago by FFF. Reason: typo

Please Log in or Create an account to join the conversation.

More
1 week 6 days ago #3 by Frank Müßner
Replied by Frank Müßner on topic Break only when Debugging
Hi Karl,

i have all compile with X86. :-)

CToD(" . . ") is only a sample that i found.

There is other Code that run without Error, but when debug the error is shown. That is my Problem.

Frank

Please Log in or Create an account to join the conversation.

More
1 week 6 days ago #4 by robert
Replied by robert on topic Break only when Debugging
Frank,
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.

Robert

XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

More
1 week 6 days ago - 1 week 6 days ago #5 by FFF
Replied by FFF on topic Break only when Debugging
Frank,
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...

Karl
Last edit: 1 week 6 days ago by FFF. Reason: typo

Please Log in or Create an account to join the conversation.

More
1 week 6 days ago #6 by Chris
Replied by Chris on topic Break only when Debugging
Hi Frank,

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 :)

Chris

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
1 week 6 days ago #7 by FFF
Replied by FFF on topic Break only when Debugging
Chris,
FTR, after setting "Break always" i see Frank's exeption dlg, too. ;)

Please Log in or Create an account to join the conversation.

More
1 week 6 days ago #8 by Frank Müßner
Replied by Frank Müßner on topic Break only when Debugging
Hi Chris,
ok i will look for the <exception name> the next time, and will play with the "Debugger Options"

Karl,
i can debug through all the shown code, too. When i have a better Sample where i have noticed this, i will make a sample.

Frank

Please Log in or Create an account to join the conversation.

More
1 week 5 days ago #9 by Frank Müßner
Replied by Frank Müßner on topic Break only when Debugging
Hello,
Maybe a better example what I mean:


[STAThreadAttribute];
FUNCTION Start( asCmdLine AS STRING[] ) AS INT
LOCAL nExitCode AS INT
LOCAL oMainWindow AS StandardSDIWindow
LOCAL oApp AS App
LOCAL aD AS ARRAY

RDDSetDefault( "DBFCDX" )

nExitCode := 0

oApp := App{}
oMainWindow := StandardSDIWindow{oApp}
oMainWindow:Show(SHOWCENTERED)

AAdd(aD,"Test")

oApp:Exec()

RETURN nExitCode

///////////
XIde XSharp/Dialect VO/X86

this code does not run, naturally because array(AD) is not initialized.
But when 'Run' i get no Error Message.

When Debug i get the right Error Message "System.NullReferenceException"

So i can not see and find any Error :-(

Frank
Attachments:

Please Log in or Create an account to join the conversation.

More
1 week 5 days ago #10 by Frank Müßner
Replied by Frank Müßner on topic Break only when Debugging
Hi,
other Sample.
Simple VO App that will open a Datawindow with ArrayServer work in VO. Transport to X# and not work. Call SELF:Use(oServer) (over FileOpen Method in Sample)
Can someone confirm this?

Frank
Attachments:

Please Log in or Create an account to join the conversation.

More
1 week 5 days ago #11 by FFF
Replied by FFF on topic Break only when Debugging
Frank,
bServer Lib is missing....

Please Log in or Create an account to join the conversation.

More
1 week 5 days ago - 1 week 5 days ago #12 by FFF
Replied by FFF on topic Break only when Debugging
You don't get Warning at F9?
EDIT -> your first sample.
Last edit: 1 week 5 days ago by FFF. Reason: additional info

Please Log in or Create an account to join the conversation.

More
1 week 5 days ago #13 by Chris
Replied by Chris on topic 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:
FUNCTION Start() AS INT
TRY
// program code...
CATCH oException AS Exception
// Display exception
END TRY

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

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
1 week 5 days ago #14 by Frank Müßner
Replied by Frank Müßner on topic Break only when Debugging

FFF wrote: You don't get Warning at F9?
EDIT -> your first sample.


No, i get no error with <F9> Compile :-)

Please Log in or Create an account to join the conversation.

More
1 week 5 days ago - 1 week 5 days ago #15 by Frank Müßner
Replied by Frank Müßner on topic 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.
Last edit: 1 week 5 days ago by Frank Müßner.

Please Log in or Create an account to join the conversation.

More
1 week 5 days ago #16 by FFF
Replied by FFF on topic Break only when Debugging
Strange, i do...

Please Log in or Create an account to join the conversation.

More
1 week 5 days ago #17 by Chris
Replied by Chris on topic 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...

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
1 week 5 days ago #18 by Chris
Replied by Chris on topic 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!

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

More
1 week 4 days ago #19 by wriedmann
Replied by wriedmann on topic 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

Please Log in or Create an account to join the conversation.

More
1 week 4 days ago #20 by Chris
Replied by Chris on topic 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

XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.