Small Bug


11-01-2008 19:42:48

I'm at the point in my project where I am starting to work on the visual side of things and decided to take a stab at QuickGUI. I'm using Shoggoth and have a working demo compiled. Everything looks good so far. I ran in to a few problems along the way, mostly minor porting problems. One of the problems was that I could not create the qgui.skinset file without first adding "./" to the fileName String in ConfigScriptSerializer::exportQueued. I'm not sure if that is a problem in any other case ( (Sadly) I'm using Windows Vista 64 :x ). The actual bug I found involved highlighting a text box that has text (that is longer than the width of the text box) backwards. Once the highlight reaches the beginning of the box, when it should start cycling back through the text, the app crashes. Other than those few things it compiled nice and seems to work great. Nice work :D .

Also, I'm not sure I explained things quite well, half the time I have no idea what I'm doing, but if the explanation was not understandable, just ask. Try and see if you get the same crash, run the demo and just use the default Username text box, and highlight it backwards. I tried searching for the bug, but the Search page hates me - I didn't find anything.


11-01-2008 19:58:04

Thanks for the input! I can add that "./", but I'm not sure what effects this may have, I don't have similar problems when running on XP.

About the Text Highlighting, I am aware of this issue, it occurs when you perform highlighting with the mouse cursor. (using the keyboard seems to work fine for me, at least) The text needs to be fixed again.. sometimes I make minor changes to it and then something else breaks.. text is a pain. :wink:

I'm adding it to my list, I'll make a round of fixes this weekend, I don't have many on my list, fortunately.


16-01-2008 22:15:13

Back again. I have a few more things to question :D .

Currently I am just using the standard windows mouse, so I hide the QuickGUI mouse at startup, the problem is that no events seem to fire when the mouse is hidden, is there a way around that? (They do fire when the mouse is shown.)

The next thing is overTransparentPixel. It just doesn't seem to work for me, which has to do with another question. I have a basic drag and drop system that I have converted to QuickGUI from another GUI. There are windows, grids, cells and items. The windows are QuickGUI::Image's which contain grids of cells, which are just point data (nothing GUI related). Items are also QuickGUI::Image's. When I click on an item, it attaches to the mouse and waits until the mouse is released and checks the items position for cells within range. There are a few problems since I converted to QuickGUI. First, the overTransparentPixel problem makes the firing of some MouseUp events not fire. Also, if the Window Image is below an Item Image, only the Window Image MouseDown event fires, even though the Item Image is above it. Next, if I do get the Item attached to the mouse, if I release it on a Window Image, the MouseUp event does not fire, which circles around to my first problem.

That may be really confusing, I am most likely doing something wrong, any info would be appreciated. :D

Edit: It seems to work fine when the Window's are hidden. But still does not work when they are visible.


17-01-2008 05:37:51

I committed methods to hide the mouse cursor:


The issue with dragging and dropping widgets has been brought up before, but I don't really understand what is going on. Can you debug to see why the events are not being called?

Are you saying the overTransparentPixel is returning false when it should be true, or vice versa? It might not be overTransparentPixel that is causing events to be fired.


17-01-2008 05:45:59

Thanks for the show/hide for the mouse cursor :D . For the drag/drop the events are being fired, it just happens, that when another item is below the item being dropped, the item below gets the event, not the item above. overTransparentPixel is not returning anything (defaults to false). I keep getting the x, y <= 0 error.

if (pt.x <= 0 || pt.y <= 0)
// something is wrong here
Ogre::LogManager::getSingletonPtr()->logMessage("Quickgui : error in Widget::overTransparentPixel getting correct Mouse to widget position");
return false;

When I just hover over a transparent pixel, the error is called. Also when the images are just static and over eachother, the below image is set to the active one. I'm not sure I am explaining this very well.

Offtopic: Is there a way to set depths for widgets or something similar to a bringToFront() method?


17-01-2008 06:20:38

What are the values of pt.x and pt.y? As you can see by the code, I try to get the pixel position relative to the image's dimensions, so that the x/y coordinates are between 0 and image width/height. It could be a math error somewhere, or how I obtain the point values.. :?

I created the function


But it only works for widgets that are in the same QuadContainer, and in the same layer. Child Layer widgets can't appear over Menu Layer widgets.

For the drag/drop problem, you'd either have to investigate and tell me the problem (in code), or wait for me to investigate on my own, which could be some time, I'm really busy these days. Sorry!


17-01-2008 19:55:56

I've been looking through the code to see if I could see why it is not firing the right events. While looking through I saw that when the mouse injects any kind of event to the GUIManager, it sorts through each child starting at the sheet level, and by quick observation I noticed that it goes by the order that they are added in. Could this be my problem? Since the targetWidget is set to the first widget in the vector that applies to the event, would that make the lower widgets get the event first? If so this could be solved by either somehow sorting the widgets on addition (could be slow) or, every mouse event, go through every child widget and return the last true returning widget (slow also). This might not even be right. Any ideas?


17-01-2008 21:12:52

You're talking about the getTargetWidget function right? The code actually gets the widget with the highest offset. You're right that this function is used all the time. I tried optimizing it by making a list sorted by offset, but I don't remember why the changes weren't committed. Optimizing this function could potentially boost performance, when it comes to moving the mouse around on screen.


17-01-2008 22:39:56

Sorry, I'm a little special :roll: . I assumed that offsets would increase per new widget (I'm not sure why I assumed that), and easily fixed this by manually setting my offsets. Everything works perfectly now, although I still get the overTransparentPixel error, which is not a big problem at all. Thanks for dealing with my stupid-ness, although I'll probably be back with more of the same :D .


17-01-2008 23:36:28

Awesome, I'm glad you got past the issue. :D

I could increase the offset of each child widget when added to a widget. I can't think of any downsides to this, right now if two widgets overlap and have the same offset, the one that gets rendered first is underneath. (not very deterministic)


17-01-2008 23:44:55

Actually I think the way it is now works perfectly for me. Since I need the item I most recently selected to render on top, I can have layers of widgets. Window images first, then item images, then the current selected item image. I can change between offsets when the item is selected or deselected.


18-01-2008 07:24:13

I'm back with more complaints :D . First I would like to say that you have come up with the most complete function set for a GUI that I have ever seen. Some of the most random things I needed with other GUI's only QuickGUI has. ( It's a good thing. :D ).

Solved Below: (Is this a feature or a bug? When calling hideCloseButton on a window, after hiding and then showing the window, the close button re-appears.)

Again, sorry for being annoying and for all the tiniest problems I seem to make for myself :oops: .

Edit: I forgot about this, I found out about 20 mins after posting that all I need to do is get the titleBar first, which contains the Close Button widget and then setShowWithParent(false); for anyone who has the same question.


18-01-2008 17:55:53

That's a bug! I thought I fixed it though..

I'll write it down and fix it, should be a really easy fix. :wink:

Thanks for the compliments... lol. Your questions are welcome, I'm happy you at least look at the code a little before forming questions. :D