Problems with the new dialog engine

[Celtic Minstrel]

(continued from here)

 

Originally Posted By: Niemand

O_0

 

That was. . . impressive. It's been over ten minutes since I ran that thing, and my system still hasn't fully recovered.

I'm so sorry...

 

Originally Posted By: Niemand

As best I can tell, what it did when I tried to edit a terrain was that it created a gigantic window, far larger than my screen, and tried to tile it with one of the background textures. It was so large, though, that the space needed to buffer it greatly exceeded the capacity of my video RAM. By the time I was able to get past it scribbling all over my screen and force quit it, it had forced everything else but the OS out of RAM and into swap space.

As I recall, the size is not consistent between times; somehow either the variables to hold the size are not being initialized, or the size is being grabbed from out-of-bounds memory (or just the wrong place in general). I think it's the former; I just can't understand how.

 

Originally Posted By: Niemand

Anyway, now that I can very much see it malfunctioning, I'll try to get some idea what's going wrong. I suggest that we take this to a thread of its own, as it may require more discussion and it would be nice to cut down on the thread hijacking/rambling in this forum.

Good idea.

[Niemand]

Quote:

As I recall, the size is not consistent between times; somehow either the variables to hold the size are not being initialized, or the size is being grabbed from out-of-bounds memory (or just the wrong place in general). I think it's the former; I just can't understand how.

I'm trying to understand where a window size is supposed to come form in the first place: there appears to be none specified in edit-terrain.xml at all, for example. Is it supposed to be dynamically sized to fit by recalcRect()?

EDIT: Yeah, I think that at least one problem is manifesting in recalcRect(). I got sick of stepping through the loop over all of the controls so I just added a print statement for the new bounds values after each iteration:

Code:

8cTextMsg "$}.0~.Wtw{hOO$KF!5wz~Wx%MU;/pK @/eQvg+l"r:588 b:3998cTextMsg "$~z0^Sph9Oa[3\U,_7Z+),LZ<UrAO]A"r:588 b:39910cTextField "arena"r:588 b:3999cLedGroup "blockage"r:10047 b:12933

It looks like the size of an LED group is being drastically miscalculated.

Aside: What on earth is the reason for generateRandomString()? If you need unique identifiers, why not use sequential numbers?

EDIT 2:

Code:

--- button.cpp	(revision 142)+++ button.cpp	(working copy)@@ -265,6 +265,7 @@ }  void cLedGroup::recalcRect(){+	SetRect(&frame,0,0,0,0); 	ledIter iter = choices.begin(); 	while(iter != choices.end()){ 		if(iter->second->frame.right > frame.right)

[Celtic Minstrel]

Originally Posted By: Niemand

Quote:

As I recall, the size is not consistent between times; somehow either the variables to hold the size are not being initialized, or the size is being grabbed from out-of-bounds memory (or just the wrong place in general). I think it's the former; I just can't understand how.

I'm trying to understand where a window size is supposed to come form in the first place: there appears to be none specified in edit-terrain.xml at all, for example. Is it supposed to be dynamically sized to fit by recalcRect()?

Oh right! I forgot about that.

Originally Posted By: Niemand

It looks like the size of an LED group is being drastically miscalculated.

Okay... that shouldn't be too hard to fix...

...oh wait, you're saying that adding a SetRect in cLedGroup::recalcRect() should fix it? Wow. That's a pretty small error. So, does it work now, then?

Originally Posted By: Niemand

Aside: What on earth is the reason for generateRandomString()? If you need unique identifiers, why not use sequential numbers?

Um... I dunno, actually. I guess I just didn't think of that. It's a good idea though.

I'm not quite sure if I strictly need unique identifiers for everything, but any control that needs to be accessed later would need a unique identifier. And those all have their identifier specified within the xml file.

[Niemand]

That fix doesn't solve everything, but it does get to the point of displaying a properly sized window with the controls laid out correctly. That window still appears in a bad place, jammed up under the menu bar, and the controls themselves don't draw properly, but it's progress.