Debugging CEGUI String
Moderators: CEGUI MVP, CEGUI Team
- Sinbad
- Not too shy to talk
- Posts: 35
- Joined: Wed Jan 12, 2005 12:06
- Location: Guernsey, Channel Islands
- Contact:
Debugging CEGUI String
I'm busy debugging my Tab Control, and I'm having to look at strings a lot. However, the CEGUI custom String class seems to defy inspection (without an ASCII table, or a cast on the internal members which gets tedious), is there a simple way to read these strings?
Thanks
Thanks
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Debugging CEGUI String
Well, I'll just tell you what I do; which is a bit wanky, but it's what I do
I expand the String in the debugger to show it's members, look for the d_quickbuff and d_buffer fields, to inspect the value drag one of these onto your memory window. d_buffer is only used when the reserve buffer for the string is > some internal value, so basically if the pointer looks invalid look at d_quickbuff instead.
It should be possible to get the VS debugger do this automatically, maybe I'll have a go at this later today; so long as Doom 3 doesn't arrive
I expand the String in the debugger to show it's members, look for the d_quickbuff and d_buffer fields, to inspect the value drag one of these onto your memory window. d_buffer is only used when the reserve buffer for the string is > some internal value, so basically if the pointer looks invalid look at d_quickbuff instead.
It should be possible to get the VS debugger do this automatically, maybe I'll have a go at this later today; so long as Doom 3 doesn't arrive
- Sinbad
- Not too shy to talk
- Posts: 35
- Joined: Wed Jan 12, 2005 12:06
- Location: Guernsey, Channel Islands
- Contact:
Debugging CEGUI String
Hehe, I hadn't thought of the memory window, I'd been casting the pointers to char*. That's a little better, thanks - I know what you mean about getting VC to do this but I hadn't had time to look into it.
I'm past all the crash bugs now, and my tab control is starting to function, although for some bizarre reason I couldn't for the life of me get the buttons to render. The pane (a custom class too) renders fine, but the TL buttons never seem to get their drawNormal() or drawPushed() methods called (I've overridden drawSelf in the core tab button to call drawNormal or drawPushed depending on whether the tab is selected). The tab area definitely has a valid region, I've traced it that far, and I even tried requesting a redraw after resizing them (onSize() calls layoutComponentWidgets(), calls setPosition / size on the buttons..). The log tells me that a button is being created based on my XML child pane. I'll admit, I was cursing
I gave up in the early hours, hoping I'll see it later on today. But if you think of anything obvious I might have missed, let me know (I realise you might not be able to answer that without seeing the code )
I'm past all the crash bugs now, and my tab control is starting to function, although for some bizarre reason I couldn't for the life of me get the buttons to render. The pane (a custom class too) renders fine, but the TL buttons never seem to get their drawNormal() or drawPushed() methods called (I've overridden drawSelf in the core tab button to call drawNormal or drawPushed depending on whether the tab is selected). The tab area definitely has a valid region, I've traced it that far, and I even tried requesting a redraw after resizing them (onSize() calls layoutComponentWidgets(), calls setPosition / size on the buttons..). The log tells me that a button is being created based on my XML child pane. I'll admit, I was cursing
I gave up in the early hours, hoping I'll see it later on today. But if you think of anything obvious I might have missed, let me know (I realise you might not be able to answer that without seeing the code )
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Debugging CEGUI String
Hehe, I hadn't thought of the memory window, I'd been casting the pointers to char*. That's a little better, thanks - I know what you mean about getting VC to do this but I hadn't had time to look into it.
I put an entry into autoexp.dat, telling it that the data was a unicode string, but this only showed the first character. The solution will be to code a quick add-in dll for the debugger, this is something I might do when I have a couple of hours spare or if I get bored
...The log tells me that a button is being created based on my XML child pane. I'll admit, I was cursing
I gave up in the early hours, hoping I'll see it later on today. But if you think of anything obvious I might have missed, let me know (I realise you might not be able to answer that without seeing the code )
I've had many issues with things not showing up.
Obvious question first - have you added the tab buttons as children to an appropriate parent window?
Much of the time my probelms with this were caused by my layout code causing some part of the area rect of the widget to be set to NAN (most of the time this was due to divide by zero) - so you might want to check the d_abs_area and d_rel_area Rects for your button windows to ensure that they are set to something appropriate. Also ensure your position and size values are appropriate for the metrics mode in use. If I think of anything else I'll obviously let you know
CE.
- Sinbad
- Not too shy to talk
- Posts: 35
- Joined: Wed Jan 12, 2005 12:06
- Location: Guernsey, Channel Islands
- Contact:
Debugging CEGUI String
Here's my structure:
I'll check all the sizes again when I get home, but I was pretty sure they were ok. Perhaps time to whack a shedload of logging on.
Code: Select all
TabControl (TLTabControl)
| (absolute width/height, about 200x500)
|
|-- Tab Button Pane (DefaultGUISheet)
| | (relative width/height, 1.0 x 0.1)
| |
| |-- Tab Button (TLTabButton)
| (relative width/height, <derived from font> x 1.0
|
|-- Tab Content Pane (TLTabPane)
| (relative width/height, 1.0 x 0.9)
|
|-- Content Area (DefaultGUISheet)
|
|-- < .. plenty of controls .. >
I'll check all the sizes again when I get home, but I was pretty sure they were ok. Perhaps time to whack a shedload of logging on.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Debugging CEGUI String
That all looks okay to me.
If the render methods for the buttons are not being called, I would concentrate my efforts on the parent window of those buttons (so, "Tab Button Pane"), since that is where the decision is made about whether or not to render them (if the parent thinks it is totally clipped, none of it's children need to be drawn, so the methods are not called).
Now, I just realised there's a bug in this idea (almost certainly unrelated to your problem); if a window is set not to be clipped by it's parent, it needs to be drawn regardless of whether the parent is fully clipped, which doesn't happen at the moment - I'll add this to the todo list.
If the render methods for the buttons are not being called, I would concentrate my efforts on the parent window of those buttons (so, "Tab Button Pane"), since that is where the decision is made about whether or not to render them (if the parent thinks it is totally clipped, none of it's children need to be drawn, so the methods are not called).
Now, I just realised there's a bug in this idea (almost certainly unrelated to your problem); if a window is set not to be clipped by it's parent, it needs to be drawn regardless of whether the parent is fully clipped, which doesn't happen at the moment - I'll add this to the todo list.
- Sinbad
- Not too shy to talk
- Posts: 35
- Joined: Wed Jan 12, 2005 12:06
- Location: Guernsey, Channel Islands
- Contact:
Debugging CEGUI String
There's nothing like a fresh head. Within 10 mins of debugging through nested Window::render calls and I realised I hadn't correctly altered some initialisation code when I changed tack late last night, to adding a pane for the tab buttons (instead of making them direct children of the tab control). Like a muppet, I'd forgotten to add the pane to the control. Shoot me, please
I have some visual glitches and event-related things to sort out, but I'm moving forward again
I have some visual glitches and event-related things to sort out, but I'm moving forward again
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Debugging CEGUI String
Hehe, it's always the silly mistakes that are really hard to see (especially when you've been staring at the code for hours)
Debugging CEGUI String
Hehe, I hadn't thought of the memory window, I'd been casting the pointers to char*. That's a little better, thanks - I know what you mean about getting VC to do this but I hadn't had time to look into it.
I put an entry into autoexp.dat, telling it that the data was a unicode string, but this only showed the first character. The solution will be to code a quick add-in dll for the debugger, this is something I might do when I have a couple of hours spare or if I get bored
.
Maybe I can help with this. If you'll put your string var into the watch window followed by ",ma" you will be able to read the string. Like this:
pMyStr->d_quickbuff,ma
It's looks a little screwy but it works.
A better solution, like Crazy Eddie mentioned, is a add-in dll. So I wrote one that decodes String and Window. You can get it here. Put it in your path along with CEGUIBase.dll, the stl DLLs and the xerces DLLs. I just put all of this into my Common\MSDev98\Bin subdir... arguably not the best approach.
Just put in your autoexp.dat file these lines:
Code: Select all
CEGUI::Window= $ADDIN(CEGUIAutoExpHlpr.dll,_AutoExpCEGUIWindow@28)
CEGUI::String= $ADDIN(CEGUIAutoExpHlpr.dll,_AutoExpCEGUIString@28)
Here are a few others I've put in my autoexp.dat that might be helpful:
Code: Select all
CEGUI::Rect= l=<d_left>,r=<d_right>,t=<d_top>,b=<d_bottom>
CEGUI::Point= <d_x>,<d_y>
CEGUI::Vector2= <d_x>,<d_y>
CEGUI::Vector3= <d_x>,<d_y>,<d_z>
I'll be happy to add any other expansions anyone would like, if they would be helpful. Just let me know.
Oh, and I've ONLY used this DLL on VC6. I have no idea if it will work with VC7.
Cheers,
Chris
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Debugging CEGUI String
I just tried it on VC7.1 and it works there too (obviously I had to have stlport, which most vc7 users do not have).
I have to say this very cool, one suggestion I have for the dll is for the Window show it's type as well as its name. I know it's possible to expand the view to get that, but you can't beat "at a glance" infomation
CE
I have to say this very cool, one suggestion I have for the dll is for the Window show it's type as well as its name. I know it's possible to expand the view to get that, but you can't beat "at a glance" infomation
CE
Debugging CEGUI String
I just tried it on VC7.1 and it works there too (obviously I had to have stlport, which most vc7 users do not have).
Great! Two environments in one!
I have to say this very cool
Thanks very much.
one suggestion I have for the dll is for the Window show it's type as well as its name. I know it's possible to expand the view to get that, but you can't beat "at a glance" infomation
Great suggestion! And it's done! Just download it again from the same link and see if you like it.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Debugging CEGUI String
Yes, I like the new summary info for Window This is very useful when debugging the middle of something and you have a Window od some description, previously you'd have no idea which window it was or what type, now we can see that instantly. Thanks
CE.
CE.
-
- Just popping in
- Posts: 19
- Joined: Tue Feb 16, 2010 00:17
Re: Debugging CEGUI String
Sorry about reviving a super old thread. I tried using the DLL posted above with VC8 and didn't have any luck. Does anyone have a .dll and source code for string and window preview for use with VC8 debugger?
Thanks!
Thanks!
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Re: Debugging CEGUI String
Hmmm, isn't it the case that you can do this in the newer IDEs without needing an actual DLL? "Data Visualisers" or some such thing... I thought we'd had something like that posted here also... If I manage to find it, I'll post back
[Edit]
I found it! Here's a link: viewtopic.php?f=2&t=3605 - it is still a DLL, anyway, I hope the post is useful
CE.
[Edit]
I found it! Here's a link: viewtopic.php?f=2&t=3605 - it is still a DLL, anyway, I hope the post is useful
CE.
Useful Links: Forum Guidelines | Documentation | Tutorials | HOWTO | Videos | Donate to CEGUI | CEGUI Twitter
-
- Just popping in
- Posts: 19
- Joined: Tue Feb 16, 2010 00:17
Re: Debugging CEGUI String
Thanks CE. That one works great on my VS2005 (VC8) system. I presume it works well on VS2008 too because that's what the author wrote it for.
BTW I did find a Data Visualizer code snippet that could inspect CEGUI::String but it does not provide an adequate "at a glance" preview and I could not figure out how to make one myself (got my hands dirty a little bit). I'm of the opinion that it is not possible without a DLL.
BTW I did find a Data Visualizer code snippet that could inspect CEGUI::String but it does not provide an adequate "at a glance" preview and I could not figure out how to make one myself (got my hands dirty a little bit). I'm of the opinion that it is not possible without a DLL.
Return to “CEGUI Library Development Discussion”
Who is online
Users browsing this forum: No registered users and 1 guest