Hi,

Lazarus has a dialog for conditional breakpoints, but it doesn't work. I tried everything.
MSEide has conditional breakpoints, but only works for integer type expressions.

I spoke to Martin (MSEide author) and he told me that GDB doesn't understand Pascal ansi-string expressions - hence conditional breakpoints as follows, can never be used.

* set a breakpoint where condition is: TypeDecl.Name = 'TRGBTriple'

The Name property doesn't have a getter function, it references the FName field variable directly - so that annoying Pascal Properties issue with GDB is not relevant here.

So I have to use a work-around by introducing a new temporary test variable and a standard non-conditional breakpoint. This works, but really sucks, because after your debugging session, you need to search for 'testvar' and delete all code using it. :-(

    s := TypeDecl.GetDeclaration(True);
    if TypeDecl.Name = 'TRGBTriple' then
      testvar := 0;          //   <<--- set normal breakpoint here
    Writeln(EscapeText(s));

More reasons I hate FPC using GDB as a debugger instead of a native written one. Does anybody know if there is a way to support Conditional Breakpoints in FPC + GDB with string types?

PS:
Anybody know how the Duby project (Object Pascal based Debugger) is progressing, and if support for it could be added to Lazarus or MSEide?

Regards,
- Graeme -

Graeme Geldenhuys wrote

PS: Anybody know how the Duby project (Object Pascal based Debugger) is progressing, and if support for it could be added to Lazarus or MSEide?

creating a debugger is not that difficult, evaluating (pascal) expressions is.
And even then evaluating properties is impossible.

Marc

Op 2010-08-13 11:22, Marc Weustink het geskryf:

creating a debugger is not that difficult, evaluating (pascal) expressions is. And even then evaluating properties is impossible.

Well, doesn't FPC evaluates expressions - so why can't a debugger? Also, couldn't Michael new Expression Parser help here?

As for the properties issue. That's a personal preference of the 'core team' as far as I know. Delphi and Kylix supports debugging Properties (even with the "possible" data changing issue) - yet I haven't seen a single posting of a Delphi developer complaining about that possible data change issue. The pros far outweigh the cons.

Hopefully Dmitry could solve these problems with Duby. I haven't evaluated Duby is some months, but last time I did check, it made good progress. I guess it's time I get another code update.

Regards,
- Graeme -

Marc Weustink wrote

creating a debugger is not that difficult, evaluating (pascal) expressions is.

There are several open source projects that provide this.

And even then evaluating properties is impossible.

AFAIK, the Delphi Debugger can.

GDB can call function in the C program it debugs. Of course these use the C (and maybe C++) ABI and not FPC's Object ABI., But when you write a new debugger, this should be possible.

-Michael

Graeme Geldenhuys wrote

Does anybody know if there is a way to support Conditional Breakpoints in FPC + GDB with string types?

It can be solved without changing anything to either FPC or GDB, by basically writing extensions for GDB in Pascal. Create a unit with a bunch of cdecl helpers to deal with types that GDB does not know about, such as ansistrings (comparison, assignment, ...). Then in the Pascal IDE,
a) when compiling a debug version, include this unit in the main program (if it gets standardised, we can include it with FPC and automatically add it when generating debug information) b) when one of those types is used in an expression, call the appropriate helper via GDB (you can include function calls in expressions).

Jnoas

Graeme Geldenhuys wrote

Hi, Lazarus has a dialog for conditional breakpoints, but it doesn't work. I tried everything.

....

* set a breakpoint where condition is: TypeDecl.Name = 'TRGBTriple'

Seems that gdb expects double quotes
FName = "abc"
but then it wants malloc to be defined, and complains about that.

It does support string index, and bool expression: FName[0]='a' and FName[1]='b'
That works (in the watches windows) [Note in Lazarus the expression isn't properly quoted before being send to gdb. So (since it has spaces) you need to double quote the entire expression, before sending it to gdb]

I can also Do:
SomeString=OtherString
So if you have the desired name in a variable...

Martin

Op 2010-08-13 11:42, Martin het geskryf:

I can also Do: SomeString=OtherString So if you have the desired name in a variable...

I tried that approach in Lazarus IDE and it doesn't work either.

Breapoint Condition: s = TypeDecl.FName

In the code s is assigned 'TRGBTriple', and the breakpoint is set on the following line. The breakpoint never got triggered.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Hopefully Dmitry could solve these problems with Duby. I haven't evaluated Duby is some months, but last time I did check, it made good progress. I guess it's time I get another code update.

No updates. Sorry.
The last changes were: reading debug information (both dwarf and stabs).

Duby only allowed to view integer variables. I couldn't get any further because the proper expression and value evaluation is required. I've started with the pascal expression parser (now contributed to passrc).

thanks,
dmitry

Do you have those spaces in the expression when you entered it? Lazarus currently fails to quote them, so that may not work then.

Op 2010-08-13 12:43, dmitry boyarintsev het geskryf:

I thought the expression parser will come in handy. :)

BTW:
I got an Duby update, and had to make one minor change to get dubyline to compile under 64-bit Linux. See patch below.

Anyway, I simplified your instruction on integrating Duby with Lazarus IDE as well. Simply add the following to the "Tools > Configure Build Lazarus > Advanced tab > Other" dialog and edit box. Obviously change the paths to match your environment.

-Fu/opt/git/duby_svn/dubylib -Fu/opt/git/duby_svn/dubylaz

Then simply add 'dubydebugger' to uses clause of the DebugManager.pas unit included with Lazarus IDE.

No need to copy Duby units to the Lazarus source directories - keeps things a bit more tidy, and development in Duby can continue, and when Lazarus gets rebuilt, Duby updates are automatically included (again no copying of units required). :-)

Duby appeared in the debugger list of Lazarus IDE, but I couldn't get it to debug a program though. I couldn't start my application via the IDE. :-/ Any hints?

-------------[ minor.patch ]----------------------- diff --git a/dubylib/nixdbgtypes.pas b/dubylib/nixdbgtypes.pas index 965a003..1dded15 100644
--- a/dubylib/nixdbgtypes.pas
+++ b/dubylib/nixdbgtypes.pas
@@ -2,7 +2,11 @@ unit nixDbgTypes;

{ Linux base debugging type }

-{$mode objfpc}{$H+}
+{$ifdef fpc}
+{$mode delphi}{$H+}
+{$else}
+{$apptype CONSOLE}
+{$endif}

 interface

---------------------------------------------------

Regards,
- Graeme -

Op 2010-08-13 13:04, Martin het geskryf:

> Do you have those spaces in the expression when you entered it? Lazarus currently fails to quote them, so that may not work then.

Ah, that could be it. I typed the expression with spaces.

Anyway, Martin's (MSEide) suggestion of the extra testvar is a bit easier while the breakpoint conditions support are flaky. So I'll rather use the testvar for now.

Regards,
- Graeme -

Can you explain this ? As far as I know, there no member of the core team that objects to having properties inspectable in the debugger ?

Michael.

Michael Van Canneyt wrote

Can you explain this ? As far as I know, there no member of the core team that objects to having properties inspectable in the debugger ?

I was obviously generalized a bit too much. If you really want me to, I can search the mailing list archive to find out who said what. Anyway, it was told many times before that inspecting a property with Getter and Setter methods may change underlying data - so the whole debugging of Properties are frowned upon.

I'm simply stating that developers should know what they are doing, and that I have never seen a Delphi developer ever complain about that "possible data change" issue. It's only FPC developers that keep mentioning it.

Actually, I just checked, it seems that (other than for evaluating watches) for break conditions, spaces are ok .

I don't know why you example doesn't work => I did some string comparisons, and they appeared to work ( AnsiStringVarOne=AnsiStringVarTwo )

Martin

IIRC that is mixing up 2 things. But in Graeme favour, likelihood has it, that others have mixed it up before: so this may have been said the way quoted (but not necessarily by people people listed)

IIRC there are several technical underlying issues (but I may be wrong): like not yet implemented to call functions from the debugger at all; and issues to represent the same symbol as getter and setter with the means of stabs/dwarf ?

The "accidental change" is more an argument, to have the function off by default.

And true, no one ever complains about having had that problem. Those who do have it are often beginners, they have no idea what it is, they blame it on their own code, and since they can't name it, they can't blame it. (IIRC that was my own experience too, a long time ago, in a galaxy right here)
[if any one feels the need to answer this last one: do it on fpc-other, or in private mail to me; or I get in trouble for having written this]

Martin

Graeme Geldenhuys wrote

More reasons I hate FPC using GDB as a debugger instead of a native written one. Does anybody know if there is a way to support Conditional Breakpoints in FPC + GDB with string types?

You could try the gdb version from Fedora, and then use dwarf-3 with fpc-trunk (-gw3). That combination supports proper displaying of varchar's. And I think it will also evaluate them right. But I didn't test it and it's all very experimental. (Other things may not work at all)

Joost.

Delphi's debugger has had the possibility to inspect properties for ages. In fact, for watches you had to tick an extra checkbox to allow for function-calling.

Using a property in delphi is ALWAYS a function-call, even when you use a read=FSomeField specifier. The debugger knows to inspect through the RTTI property-tables and finds which call to make and type to expect.

As for why Delphi devs who don't complain: I for one couldn't get the lazarus-bundled/integrated-debugger to work on windows except for a few trivial cases. (about half a year ago) Also, using Delphi for this many years now (10+), I guess I must have been spoiled because GDB just doesn't do it for me (and the 100000000000 windows lazarus opens are a nightmare). Stepping in assembler or changing a register didn't work at that time (both trunk and official release) without AV's.

At that time it was stated that the debugger was under construction. So I did the next best thing ever since: develop+debug on Delphi then "port" to fpc.

But instead of complaining, I'd better check the current status.

My point being: when working on windows, coming from Delphi, the debugger needs getting used to and has it's limitations. When you have Delphi, you can use it's debugger.

btw, the whole debugger back-end was written for *nix anyway, especially when you consider the whole "I need a outputwindow for console debugging" vs "that problem does not exist on *nix, just open another terminal and problem solved" discussion of a few weeks back.

ps: will check if my problems still exist with more current Lazarus (latest trunk update was 3 or 4 months ago) and if so, will "complain" in mantis :-)

kind regards,
Dimitri Smits

btw, what I forgot to respond to in my last mail of a few mins ago: a getter is not supposed to change anything, when working in a correct OO way. a modifier/setter is the way to change data. The inspector can use both. Watches only getters.

So I fail to see the problem: when you CHANGE the value, it is because you explicitly did so through the inspector (ad-hoc expression evaluator should not allow this, just through inspector).

Those who frown upon that, need to reschool themselves in OO practices, because then they are using it incorrectly ;-)

Correcting/contradicting myself a little bit:
The reason that the checkbox in delphi watches is needed and the only thing that CAN change something in the internals of an object is when you have somesort of lazy-loading (be it from cache, db, ...) behind a getter. That is the reason why you need to explicitize to the developer who is supposed to know what (s)he is doing.

kind regards,
Dimitri Smits

Op 2010-08-13 14:08, Dimitri Smits het geskryf:

btw, what I forgot to respond to in my last mail of a few mins ago:

[...off-topic...]

I'm not arguing with anything you said, just want to add something I only now remembered from my Delphi days.

The Delphi debugger allowed you to change values while debugging, then step back and re-execute that code with new values [I think I did this back in the days of Delphi 5]. Delphi's debugger was pretty damn awesome - just makes me realize how crap GDB is (with any other languages than C). And what is really sad is that I got used to the dismal state of FPC debugging over the years - moving back to writeln() statements and log files for 90% of my debugging needs.

Regards,
- Graeme -

The above has nothing to do with C or any other language. You can also change the value of variables in GDB and change the value of the instruction pointer. And yes, for certain FPC-specific types you need helpers, but as I explained those can be programmed in Pascal.

Programming them in Pascal code that is linked into the target program moreover has the advantage that GDB (or any other debugger, even one written in Pascal) doesn't have to be changed whenever FPC's implementation logic changes (and/or that it doesn't have to contain support for multiple FPC versions).

Jonas

In our previous episode, dmitry boyarintsev said:

I've started with the pascal expression parser (now contributed to passrc).

a propos, added a --parse-impl option to fpdoc, to keep the implementation parsing testable without recompilation or distubing doc generation.

I quickly tried to run it on the rtl docs, but mostly seem to be includefiles (I don't know why it can't find them, most -Fi's seem ot be there?)

/fpc/fpc/rtl/objpas/sysutils/syspch.inc(29,17): Could not find include file / 'strings.inc '
../fpc/rtl/inc/strings.pp(109,17): Could not find include file 'strings.inc / '
../fpc/rtl/unix/video.pp(873,5): Syntax error at token "label" ../fpc/rtl/inc/heaptrc.pp(930,5): Syntax error at token "label" ../fpc/rtl/i386/mmx.pp(74,24): Syntax error at token "Number" ../fpc/rtl/go32v2/emu387.pp(45,24): Syntax error at token "Identifier xffff" ../fpc/rtl/go32v2/go32.pp(226,21): Syntax error at token "Number" ../fpc/rtl/linux/gpm.pp(412,5): Syntax error at token "label" ../fpc/rtl/linux/oldlinux.pp(1618,16): Could not find include file 'textrec.inc'
../fpc/rtl/unix/bunxovl.inc(16,16): Could not find include file 'textrec.inc'
../fpc/rtl/unix/unix.pp(167,16): Could not find include file 'textrec.inc' /fpc/fpc/rtl/objpas/classes/classes.inc(208,17): Could not find include file / 'persist.inc '
../fpc/rtl/unix/unixutil.pp(46,16): Could not find include file / 'textrec.inc'
../fpc/rtl/unix/x86.pp(66,4): Expected "." at token ";" ../fpc/rtl/linux/linux.pp(364,19): Syntax error at token "Identifier sp" /fpc/fpc/rtl/i386/mathu.inc(18,5): Syntax error at token "asm" ../fpc/rtl/linux/ostypes.inc(86,13): Could not find include file 'stat.inc' ../fpc/rtl/unix/clocale.pp(59,19): Expected "

Nono, "Frowned upon" doesn't mean it won't get implemented.

But it may be that GDB has serious implementation problems with it. The inner workings of GDB are close to black magic from what I hear, so...

Michael.

Op 2010-08-13 14:46, Jonas Maebe het geskryf:

Programming them in Pascal code that is linked into the target program moreover has the advantage that GDB (or any other debugger, even one

Do you have any web link on how to do this, or a small single case example that could be built on to? I don't mind working on this, I just don't really know how or what is required - and thus where to start.

Regards,
- Graeme -

{ the "export" is so the compiler uses C-style name mangling, which is
required to get predictable function names in the machine code }
function debugger_compare_ansistr(const a1,a2: ansistring): longint;
cdecl; export;
begin
   result:=SysUtils.AnsiCompareStr(a1,a2);
end;
procedure debugger_assign_ansistr(var dest: ansistring; const src:
ansistring); cdecl; export;
begin
   dest:=src;
end;

...

Create such routines for any operation on any type that GDB cannot handle directly (assigning, comparing, printing, modifying, ...). You can probably even add support for properties via RTTI lookups this way.

One main rule I can think of: parameters of automated types *must* all be either "var" or "const" parameters (because otherwise the caller side has to call special routines prior to invoking the helper, which the debugger won't do).

After this unit is implemented, debugger frontends will obviously still need to get support for calling these helpers whenever they detect that types are involved in expressions.

Jonas

Yeah, and this is exactly the reason why I stopped on expressions. There is no way to distinguish beween a pchar and a string "string"

FName[1] (where FName:PChar) has a complete different meaning than FName[1] (where Fname:String)

That works (in the watches windows)

it works, but does it show the correct value ?

[Note in Lazarus the expression isn't properly quoted before being send to gdb. So (since it has spaces) you need to double quote the entire expression, before sending it to gdb]

It is quoted iirc (or did I forget it somewhere ?).

Marc

I was partly mistaken.
the command for setting a breakpoint expression, is ok => special chars (non printable) are quoted. And gdb accepts the overall expression with spaces, and has no problems with those spaces.

For the watch window it's different:

If I want to see the last 3 bits:
SomeIntVar and 7

That does not work. But I can enter the same term into the watch window, with doublequotes and it will work
"SomeIntVar and 7"

So for the watch window, quoting is still incomplete.

did some more testing:

ROUND 4

1. minor note: We should not forget that field names are case sensitive in ExtJS, so any database field names need to be entered exactly: ex:
fields: ["id","login","name","email", "lastlogin"] is not the same as
fields: ["ID","LOGIN","NAME","EMAIL", "LASTLOGIN"]

or
{header: 'ID', dataIndex: "id", sortable: true, hidden: true}, is not the same as
{header: 'ID', dataIndex: "ID", sortable: true, hidden: true},

In the demo projects a DBF table is used with all capital letter field names. When I tried to use MySQL, it took me some time to realize this problem. Having zero errors displayed for this didn't help either :)

2. major: It seems that the error/exception handling does not have the proper server responses for ExtJS (when read/insert/update/delete happens on the data), because with any exceptions there is nothing displayed but the empty grid with "no data to display" note. Apparently, we need to append a '"rows" : ""' to our responses in order for ExtJS to properly accept our reply with the error message (being "rows" is our root element and ExtJS requires this): ex: instead of
{ "success" : false, "message" : "Blahblah exception occured CGI side" }

it should be

'{ "success" : false, "message" : "Blahblah exception occured CGI side", "rows" : ""}

(not sure how using XML instead of JSON needs this done differently) This needs to be done within our reply generation internally (fcl-web) when there is an error/exception or the message will never be displayed client side. Explanation:
In our *.js we have
data.addListener('exception', function(proxy, type, action, options, res) { if (type === 'remote') {
Ext.Msg.show({
title: 'REMOTE EXCEPTION',
msg: res.message,
icon: Ext.MessageBox.ERROR,
buttons: Ext.Msg.OK

         });
     }
   });

ExtJS however, will only have 'remote' type if the server response is proper for it (having a root /which is "rows"/ in our case), all other cases instead of 'remote' it has the type 'response', regardless of our "success" property being true or false.

AB

Yes.
The case sensitivity of Javascript (and hence JSON) has given me grey hairs prematurely :-)

This is ExtJS boilerplate code, with nothing FPC specific about it.

ExtJS however, will only have 'remote' type if the server response is proper for it (having a root /which is "rows"/ in our case), all other cases instead of 'remote' it has the type 'response', regardless of our "success" property being true or false.

Unfortunately, the ExtJS documentation is rather terse where this is concerned.

So, if "rows" is not supplied, type='response' and the 'success' property must simply be checked ? Or do you suggest adding "rows" to the error response ?

I'm not sure if this is also the case if you are using a DirectStore ?

Michael.

...snip...

ExtJS however, will only have 'remote' type if the server response is

proper for it (having a root /which is "rows"/ in our case), all other cases instead of 'remote' it has the type 'response', regardless of our "success" property being true or false.

Unfortunately, the ExtJS documentation is rather terse where this is

concerned.

So, if "rows" is not supplied, type='response' and the 'success'

property must simply be checked ? Or do you suggest adding "rows" to the error response ?

I'm not sure if this is also the case if you are using a DirectStore ?

The docs for Ext.DataProxy -> events -> exception says it in more detail. "
Fires if an exception occurs in the Proxy during a remote request. This event is relayed through a corresponding Ext.data.Store.exception, so any Store instance may observe this event.
...
# type : String

The value of this parameter will be either 'response' or 'remote'.

* 'response' :
An invalid response from the server was returned: either 404, 500 or the response meta-data does not match that defined in the DataReader (e.g.: root, idProperty, successProperty).

* 'remote' :
A valid response was returned from the server having successProperty === false. This response might contain an error-message sent from the server. For example, the user may have failed authentication/authorization or a database validation error occurred. "

We are always getting type='response' now (due to "response meta-data does not match that defined in the DataReader") with the "rows" not being there when an exception/error happens server side, so no error message we pass is processed in our ExtJS.
I do not know about DirectStore, I just started with ExtJS/JSON with playing with the demo apps from fcl-web a few days ago :) Does it hurt anything if we just append a "rows":"" to our error/exception replies? I did that with the 1st demo app and it works so far, displays the errors from the server side now (like "DB field X cannot be null", "Cannot connect to DB server", "Invalid DB user", etc.).

AB

I don't 100% agree: the exception() handler must also be able to handle 'response'. If there is a server crash or so (which will result in a 500 error code) , it must also be able to handle that.

We can add the "rows" for convenience, but nevertheless the error handler must also handle the 'response' case.

Michael.

...snip...

just found this:
It seems that someone had the same problem with ExtJS and even created a bug report there:

http://www.sencha.com/forum/showthread.php?91903-OPEN-826-DataProxy-Exception-JsonReader-Possible-Inconsistency

He did the same adding the "rows" trick to solve it. The problem is, that when the 'response' case comes, the object is not processed (because the exception is thrown from within ExtJS before the response is really processed) so we cannot access the response properties to display it to the client. Might be only a problem with JSON reader, I am not sure.

AB

..snip...

We can add the "rows" for convenience, but nevertheless the error handler must also handle the 'response' case. Michael.

Hi Michael,

I've created an updated ExtJS error handler for the demo programs that handle all these response messages from FCL-web without the need to change the internals and play with the "rows". We just need to update the *.js files for the demos.

=================================CODE START

   // Listen to errors.
   data.addListener('exception', function(proxy, type, action, options,

res) {
if (type === 'remote') {
Ext.Msg.show({
title: 'REMOTE EXCEPTION',
msg: res.message,
icon: Ext.MessageBox.ERROR,
buttons: Ext.Msg.OK

         });
     }else{//type === 'response'
       if (res.responseText !== undefined){//there is a responseText so

we can process

         var succ = undefined;
         var mess = "";
         try {

//////mark start

           var response = Ext.util.JSON.decode(res.responseText);
           succ = response.success;
           mess = response.message;

//////mark end
if ((succ !== undefined)&&(!succ)){//success == false Ext.Msg.show({
title: 'REMOTE EXCEPTION/ERROR',
msg: mess,
icon: Ext.MessageBox.ERROR,
buttons: Ext.Msg.OK

             });
           };
         }//try
         catch (err) {
         	Ext.MessageBox.alert('ERROR', 'Could not decode server

response: ' + res.responseText);

         };//catch
       };
     };//else
   });//addListener

==================================CODE END
For XML communication we need to change between the "mark start / mark end" to
//////mark start

           var response = document.createElement('div');
           response.innerHTML = res.responseText;
           s = Ext.DomQuery.selectValue('success', response);
           switch (s.toLowerCase()) {
             case "true" : succ = true;
             case "false": succ = false;
           };//switch
           mess = Ext.DomQuery.selectValue('message', response);

//////mark end

AB

Hi,

1. Should not the JSON replies have a "total" returned always like the XML replies?
Right now "total" is not returned if the "start"/"limit" is not passed to the formatter.

2. How can I provide the correct "total" for the response if I only loaded exactly the records requested by ExtJS into the dataset but not the whole table?
Ex: Have a table with 1000 records, I'm on page 2 of the grid that has a page limit of 50 records.
Of the total 1000 records, only about one third should be visible for the person currently requesting data.
Therefore, I run a SQL statement to get those next 50 records from the 333 potential ones for this person, and that will be displayed in the grid, and only those 50.
This way, only I can tell in the response the correct "total", which is 333 in this case. 50 was passed to the formatter/adapter.

Thanks,

AB

As far as I understand it, total is only needed when you do paging; Paging is indicated with the start/limit.

Well, I have no idea. As far as I know, the 'total' is only needed for display purposes in a paging grid. You'd need to run a second query which counts the number of records that would be returned if no paging was requested.

Michael.

...snip...

Hi Michael,

I understand.
However, how do we send back our own "total" we got from our second query? How do we append/update it into the response?

With XML, FCL-web always appends a "total" so that should be overwritten somehow.

I guess we can trick FCL-web to not append its own "total" with JSON by sending only the 50 records needed and saying to it that the "start" is the 1st one and "limit" per page is 51 even if those 50 come from a table of 1 million records.

It seems we need to manipulate the tmemorystream that is generated by the formatter? Maybe we should make this a little bit easier for developers somehow.

AB

Good point.

Yes. I don't think you should manipulate the stream; it is too slow.

I will add an 'AfterFormatResult' or so event;
Likewise I will add a AfterRow event, so it is possible to append extra data to a row. I think we should do this for both XML and JSON, so the row/response elements can easily be accessed. The question is now,
a) do I make this a TNotifyEvent, and make a Property Response/CurrentRow which can be used or
b) do I pass Response/CurrentRow to a new event handler type for these events ?

Doing a) means I can introduce it at a higher level, but b) seems more clean.

Michael.

...snip...

Sounds good. For me personally, it does not matter either way, just need to make this work :) . If we can intercept/access these row/response elements in an easy way, I'm happy.

AB

I implemented b), see revision 15859.

I also now add a 'rows' property to the error response object, so the ExtJS exception handling will work with 'remote'.

I'm still doubting to implement an OnErrorResponse event. It may be useful for logging purposes, or to change the reported error, since there is no way to intercept that currently. What do you think ?

Michael.

...snip...

I will check it in the morning to see if I can change/update the "total" field, definitely.

Some kind of built-in error response possibility would be nice too. Right now I'm hard coding things like
Response.Content := '{ "success" : false, "message" : "' + MyErrMsg + '"}'; when there was an exception in my code or incorrect user entry was passed from the client, etc.

AB

Exceptions are usually caught and transformed to the correct response. I coded an event that allows to influence this process.

Michael.

...snip...

Yes, the ones raised within FCL-web are caught. I was thinking about the ones raised within the developer's code, when handling the actions, or checking the user input from form submit, etc.
For example if I have a login form and ExtJS submits it to the server, but the login or password didn't match, we need to reply with a success=false and an error message in a proper response format. I was thinking there could be something available for the developers to help format this response properly to ExJS.
It's not a big deal though, one can always just do a

     except
       on E: Exception do
Response.Content := '{ "success" : false, "message" : "' + E.Message +
'"}';
     end

AB

I have the same kind of thing. I just do a

   Raise Exception.Create('Username and password do not match');

fcl-web catches it and returns a proper error response to the browser.

I was thinking there could be something available for the developers to help format this response properly to ExJS.

There is no need. Just raise the exception. FCl-web takes care of the rest.

If you want to do things manually, you can use

function CreateJSONErrorObject(Const AMessage : String; Const ACode : Integer) : TJSONObject;
// Create a JSON RPC 2 error response object containing an 'Error' object.
// Result is of type TJSONErrorObject
function CreateJSON2ErrorResponse(Const AMessage : String; Const ACode : Integer; ID : TJSONData = Nil; idname : TJSONStringType = 'id' ) : TJSONObject;
function CreateJSON2ErrorResponse(Const AFormat : String; Args : Array of const; Const ACode : Integer; ID : TJSONData = Nil; idname : TJSONStringType = 'id') : TJSONO

These functions from fpjsonrpc.pp return an object and you can do

Response.Content:=MyErr.asJSON;

Michael.

I implemented b), see revision 15859.

Tested it, and it seems to work nicely both for JSON and XML. I'm using the AfterDataToJSON and AfterDataToXML events to replace/insert the correct "total" now.

The only thing I've noticed is that with XML the "text" MySQL fields are not coming over to ExtJS, they only say "(MEMO)" . Is that because XML does not allow UTF8 or something?
Some non-"text" fields are also displaying strange characters with XML where with JSON everything is good.

AB

No, this is a bug. I fixed it already in JSON (since I use that), but not yet in XML.

Some non-"text" fields are also displaying strange characters with XML where with JSON everything is good.

That is an encoding issue. The XML components need to know what kind of codepage you use. I think we'll have to introduce a property for this in the dataformatter. It will introduce some overhead :/

Michael.

...snip...

Yes, I will use JSON in my project also, it seems much better and easier, I was just testing both. XML is a lot of overhead and bloat in any project both development, execution and data-size-wise.

I did some testing on the exception catching, but if I intentionally do something nasty within my Except/End part, FCL-Web replies with a web page ("Module error", or something similar), and not a JSON reply so ExtJS cannot process the response.

AB

...snip...

Yes, I will use JSON in my project also, it seems much better and easier, I was just testing both. XML is a lot of overhead and bloat in any project both development, execution and data-size-wise.

I did some testing on the exception catching, but if I intentionally do something nasty within my Except/End part, FCL-Web replies with a web page ("Module error", or something similar), and not a JSON reply so ExtJS cannot process the response.

AB

Exactly my thoughts :-)

You use simple actions ? Why not RPC-Handlers and a JSONRPCDispatcher ? That is what catches the error, plus it can create an Ext.Direct API.

The idea is that you have 1 JSONRPCDispatcher, and several RPC-Handlers. The request must be directed to the JSONRPCDispatcher, it will find the correct RPC-Handler, let it execute the request, and then returns the result as JSON to the browser. If an execution error happens in the RPC-Handler, it will be transformed to an appropriate response.

Michael.