Debug question!

[PB]

> Maybe you could use DbgPrint and DebugView

Why? Too much work when my macro solves the problem perfectly.
It still allows Debugs to work but doesn't include any of the code in
the final executable; not even imports as Freak said.

[Fred]

Actually it was a bug, it's now fixed.

[srod]

Actually it was a bug, it's now fixed.

There you are look at that; an innocent question results in a bug fix!

That's debugging for you!

[idle]

There's one for the books, how to debug the debugger.

[freak]

> how to debug the debugger.

There is a good reason why the debugger can debug itself. Helped us avoid a lot of trouble.
We can even use the 32bit debugger to debug the 64bit one and vice versa

That said, this was actually a compiler problem, not a debugger one

[idle]

Having a debugger that can debug a debugger is a very handy but I've yet to find a debugger that can prevent me from saying bugger while in the debugger, debugging my buggered code.

[Vera]

Hello,

I'm glad I found this fitting topic to ask a small Debug question!

After creating an XML and applying a handful of nodes and I can save the whole creation as a file, but I would like to view the XML-code directly without the indirect way of producing an external file. How does one grab the contents behind an adress ?

xml = CreateXML(#PB_Any)
create several nodes + items
Debug "the contents behind the adressID of xml" ?

greetings ~ Vera

[Vera]

This makes me really sad, that there is not the slightest attempt to help me out of this dilemma, not knowing where PB adresses/memorizes various informations and which maybe classical ways to get hold of them.

Even if it is impossible to attain certain allocated string-datas for further processing it would be helpful to know this as a fact and how one could work around it.

[blueznl]

Vera Vera... just a day has passed, are you not exaggerating a little?

[freak]

Try ExportXML().

This makes me really sad, that there is not the slightest attempt to help me out of this dilemma, not knowing where PB adresses/memorizes various informations and which maybe classical ways to get hold of them.

No comment.

[cas]

Or, if you only want to read it then you can use:

Code: Select all

xml = CreateXML(#PB_Any)

;create several nodes + items

ShowLibraryViewer("xml",xml)
CallDebugger

[Vera]

Vera Vera... just a day has passed, are you not exaggerating a little?

Two days and proceeded to page 3 and many have regarded this posting and none of them bothered to give a short hint. Nobody would come back days later to leave a note.
Even you prefer to keep it unanswered.

This makes me really sad, that there is not the slightest attempt to help me out of this dilemma, not knowing where PB adresses/memorizes various informations and which maybe classical ways to get hold of them.

No comment.

Exactely what I told you about twice already - making friendly requests will be neglected although maybe a single word could give an answer.

Try ExportXML().
tried -
but unfortunately this even leads me into more confusion as it needs to handle AllocateMemory() as well. It also seems an indirect route, as the string data already exists. It would be as indirect as re-reading is from a created file.

Or, if you only want to read it then you can use:

Code: Select all

ShowLibraryViewer("xml",xml)
CallDebugger

thanks - I haven't come across this tool yet, and give it a closer look later on. On first glance I see it does not show me the plain xml-code but gives me the opportunity to check the tree - nice to know.


Maybe it's simply impossible what I want but if this command
SaveXML(xml, "new.xml")
writes a single string into a file then why can't I resolve this 'already memorized' string of text as a string, so that I could e.g. debug it or show it in an explorer gadget or process it otherwise?

greetings ~ Vera

[blueznl]

Vera, this forum is by primarily by and for hobby users and volunteers. I cannot force, or even expect, other forum users to give an answer. I cannot even be angry about it, disappointed, or outright in tears if they do not answer me. It's their free choice...

Perhaps nobody is in the mood to answer a particular question, perhaps they're all teaming up to frustrate you (hey, not being paranoid doesn't mean they're not out there to get you! ), perhaps X-mas is looming near and people had to choose between typing up that word shattering life improving answer to all questions reply, and carrying the wife's shopping.

I don't know.

Take it easy. Some of my questions were not answered for ages either... and look how brilliant I have become Thanks to all those non-replies I had to figure it out myself, and now I'm definitely settled and on my way to world domination, and all those non-replying forum members will become my slaves, mowhahahahahahahaargh... excuse me, peanut (cough).

[Trond]

Try ExportXML().
tried -
but unfortunately this even leads me into more confusion as it needs to handle AllocateMemory() as well. It also seems an indirect route, as the string data already exists.

I am quite confident when I say that the string data does not exist. The xml library very likely handles the xml file not as a string, but rather as a tree structure, where each node is allocated as a separate memory area.

Since you asked so politely, here's one simple way to use ExportXML() to get a string:

Code: Select all

Procedure.s XmlToString(xml)
  Protected Size = ExportXMLSize(xml)
  Protected Value.s = Space(Size)
  ExportXML(xml, @Value, Size)
  ProcedureReturn Value
EndProcedure

[freak]

This makes me really sad, that there is not the slightest attempt to help me out of this dilemma, not knowing where PB adresses/memorizes various informations and which maybe classical ways to get hold of them.

No comment.

Exactely what I told you about twice already - making friendly requests will be neglected although maybe a single word could give an answer.

People have a life, you know. Not everybody is waiting just to answer your questions.
If you can't even show a little patience then even less people will make the effort to help you.