For a Java/Eclipse environment there is the "Expressions" view in the debug perspective which can be used to execute a set of run-time supplied code snippets each time the execution is paused , e.g. SDOUtil.printDataObject(dob) , so that pretty much gives the convenience of the embedded string representation without the performance overhead (or for less frequent update you can use the "Display" view). Do you have something similar in your development environment?
On 07/08/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
I think the SDOUtils method is the way to go. Maintaining a serialized form in the DO would killl performance as it would have to be re-serialized on every change. I have a printDataObject and printTypes methods in SCA which I think are better than the ones in SDOUtil ;-) Maybe we should add the extra function into SDOUtils. Cheers, On 07/08/06, Simon Laws <[EMAIL PROTECTED]> wrote: > > I think that would be a splendid idea. When I was playing with big bank > (which I hope to get back to shortly) I ended up using the > SDOUtils:printDataObject() method at strategic points in the code. As you > say it's very difficult to tell what's going on in GDB. > > Regards > > Simon > > On 8/7/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > I'm finding SDO DataObjects a little difficult to inspect with the GDB > > debugger. Is there anything that could be done to help debuggers display > > the contents of SDO DataObjects, properties and types? > > > > Just an idea... but would it make sense to add to SDO DataObject a > > string member containing its serialized contents, only when compiled > > with the debug option maybe... Would that help? > > > > Any thoughts? > > > > -- > > Jean-Sebastien > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- Pete
-- Best Regards Kelvin Goodson
