Scrollbars, again

I am getting problems with scrollbars again in rev 184. They simple do not appear any more. Updating from something around 160 to 184 broke all of my GUI because of the API changes. So far I was only able to restore the console, but this is a GUI element, that should definitely show a scroll bar (it did so before).

Here is some sample code:


QuickGUI::Rect Rect (10, Height*(1+d_Lines.size()),
d_Text->getSize().width-20, Height);

QuickGUI::Label *Label = d_Text->createLabel();
Label->setDimensions (Rect);
Label->setText (Message);
Label->setHorizontalAlignment (QuickGUI::Label::HA_LEFT);


The Labels appear as expected, one below the other. But when they reach the lower border of the window (so the vertical size is exceeded) the scrollbar does not appear.

It could be that you need to call

Panel/List :: allowScrolling(true);

Another user requested to be able to turn off scrolling for certain widgets. (This allows hiding widgets when they are outside parent bounds, I believe he was doing some gui animation)

Also, if you want a particular widget to not influence the scroll bar, you can call

Widget::setScrollPaneAccessible(bool);

And regarding the Console widget, I will make one, it won't be any effort at all, once I finish the MultiLineLabel.

Sorry for all the API changes.

Don't worry about the API changes. But we have other problems now. I am getting crashes and lock-ups after using the scrollbars. I will have to investigate that further (not sure, if I can find the time for it today), but since it showed up only after the latest QuickGUI updates and furthermore the other crash (http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=5494) is still happening, I am starting to get suspicious.
I haven't changed my source (except for compensating the API changes), so the only change was the shift to a new version of QuickGUI. That doesn't prove that it is QuickGUI's fault. Could be a bug in my code, that just got unveiled by the changes in QuickGUI. But at least QuickGUI looks like the most likely candidate.

Was easier to get it repeatable than I expected (though I am not sure, if I covered all the cases). Happens after scrolling and then hiding the window (which is the parent of the widget with the scrollbar). Here is the stack:


#0 005E84AC ZN8QuickGUI6Widget7enabledEv() (C:\code\TinEngine\Core\Test\QuickGUI.dll:??)

#1 005B803B ZN8QuickGUI10GUIManager15setActiveWidgetEPNS_6WidgetE() (C:\code\TinEngine\Core\Test\QuickGUI.dll:??)

#2 005E8FF5 ZN8QuickGUI6Widget4hideEv() (C:\code\TinEngine\Core\Test\QuickGUI.dll:??)

#3 005B0A07 ZN8QuickGUI5Label4hideEv() (C:\code\TinEngine\Core\Test\QuickGUI.dll:??)

#4 005E8FAF ZN8QuickGUI6Widget4hideEv() (C:\code\TinEngine\Core\Test\QuickGUI.dll:??)

#5 005E8FAF ZN8QuickGUI6Widget4hideEv() (C:\code\TinEngine\Core\Test\QuickGUI.dll:??)

#6 005E8FAF ZN8QuickGUI6Widget4hideEv() (C:\code\TinEngine\Core\Test\QuickGUI.dll:??)

#7 0042ACC3 tcg::console::Hide() (??:??)

#8 0042BE69 tcg::console::Toggle() (??:??)

#9 0042B08B tcg::console::KeyPressed() (??:??)

#10 004133F5 tcb::key_handler::InjectDownEvent() (??:??)

#11 0040C6A7 tcb::facade::keyPressed() (??:??)

#12 6DA0B190 ZN3OIS8Keyboard14isModifierDownENS0_8ModifierE() (C:\code\TinEngine\Core\Test\OIS.dll:??)

#13 0041A0FB tcf::engine::frameStarted() (??:??)

#14 6511CEB1 ZN4Ogre4Root17_fireFrameStartedERNS_10FrameEventE() (C:\code\TinEngine\Core\Test\OgreMain.dll:??)

#15 65124E2D ZN4Ogre4Root14startRenderingEv() (C:\code\TinEngine\Core\Test\OgreMain.dll:??)

#16 0042240B tcf::engine::Invoke() (??:??)

#17 00406581 main() (??:??)

I will repro this and investigate. I'm surprised the deletion of the window is still crashing, I got it working on my end. Will look at it again. What widgets are in the window, in case this is relevant?

The console is a window, which cointains TextBox and a Panel, which contains more TextBoxes.

The other window contains only a single Image (I posted the code for its creation in the other thread).

Zini, I didn't try the scrolling then deleting, but I did fix an important bug related to destroying the Window/Panel widgets.

Also fixed a bug in ScrollPane::scrollIntoView.

Hopefully the problem is solved, but if not, definately let me know.

And thanks for helping me out with this, its much appreciated. The next release should have stability somewhere in the priority list.

The other crash has been fixed. Now only the scrollbar problem is left (unfortunately quite a showstopper). btw. it is not scoll-delete-crash, but scroll-hide-crash.

Edit: Actually after scrolling, pretty much everything GUI-related leads to a crash.

Edit: Or maybe not.Sometimes there is a crash, sometimes not. This looks pretty bad. I will have to investigate further.

Its getting more and more obscure. I noticed, that sometimes while scrolling the focus is taken away from another widget (in my case the console input widget). I am not 100% sure, but it seems the program only crashes on hiding the console, if this has happend before.

Ok, I will try to repro this then.

When you say the Console Input loses focus, can you describe the intended behavior you want?

1. Type input into console input box.
2. Scroll through console output.
3. Type input into console input box.

Are you saying that clicking the slider button of the scroll bar takes away focus from the input box, so you have to click it again to type?

1. Type input into console input box.
2. Scroll through console output.
3. Type input into console input box.


Correct.


Are you saying that clicking the slider button of the scroll bar takes away focus from the input box, so you have to click it again to type?


Actually I am dragging the slider. Haven't checked, if the same happens when clicking the button. But it only happens sometimes (probably depending on slider position, but it is hard to get consistent results here). Clicking the input box doesn't help in this situation, since it doesn't give back the focus any more.

After you drag the slider you cannot select the InputBox? (meaning you cannot type any more?)

Correct, but only if the input box loses the focus while dragging.

It feels natural to me that clicking and dragging on a slider makes the slider become the active widget. In the demo I can always click on the Console Input Box after dragging the slider and type.

I did fix a crash caused when I dragged the slider and closed the window. The crash was not really a result of dragging the slider, I'm wondering why I didn't see it before. Hopefully that resolves the crashes you've been getting.

I need more explanation about the problem you're experience with not being able to type in the console's input box, I can't clearly see the problem.

I can confirm, that the crash is gone. Thank you!

The input problem is still there. It happens, when while scrolling the focus is taking away from the input widget (please note that scrolling does not always take away the focus; looks like another bug).
After that I can't input anything nor can I move the text cursor. But when I move with the mouse over the input widget, a part of the input text is selected.


It feels natural to me that clicking and dragging on a slider makes the slider become the active widget. In the demo I can always click on the Console Input Box after dragging the slider and type.


I disagree here. I don't see, why the slider should take the focus at all. It is true, that I can click on the input box again after dragging, but that is interrupting the typing. Maybe we can have another method, that tells the scrollbar, if it should take the focus on click or not? (like setGainFocusOnClick for widgets)

And since we are at it, I would like to request another small feature (taken from my beloved RISC OS). Could you modify the scrollbar to invert the scroll direction when it is clicked with the right mouse button? i.e. if you click on the bottom button with the right mouse button, the scrollbar would behave as if the top button had been clicked. Same for the area between the buttons and the slider.

Are you using the Console Widget, or a Console made up of a composition of widgets? Also, can you outline a scenario (just for my understanding) of when you'd want to partially type something, then scroll to a certain part of the console output, and then resume typing again? It seems like the scrolling is interrupting, but if it's some necessary procedure to complete the input message, it would make sense to me.

The problem right now, is that, while I'd have to check the code, I think you can only drag active widgets. Which means the slider has to be active. I don't know the previous active widget, I'd have to make more bookkeeping to know this.

I just thought a solution.

I will have all the ScrollBar's children (scroll buttons, slider) propogate the EVENT_ON_CHARACTER and EVENT_KEY_PRESSED events. And then I can make the Console have handlers, such that when keys are pressed (enter) or characters input, the InputBox will be set as active widget, and the events will be carried over.

As for the ScrollBar use, I am not familiar with it, seems a little awkward, but at the same time, the right mouse button doesn't really have a use for scroll bars, so I don't think it will be a problem. I'll add it in when I get a chance.

Are you using the Console Widget, or a Console made up of a composition of widgets?


I am using a console made up of composition of widgets. Since it is already fully operational and does everything I want, I don't really see a reason to replace it with another (QuickGUI-internal) solution at this point.


Also, can you outline a scenario (just for my understanding) of when you'd want to partially type something, then scroll to a certain part of the console output, and then resume typing again?


Well, I would consider this a quite common scenario. But that is probably because of my RISC OS-heritage, where it is completely normal to operate at the same time with mouse and keyboard in two independent parts of the same window (or even in different windows). People do that all the time under RISC OS because, there is no concept of an active window and the focus is only relevant for keyboard input. I am aware that on Windows the situation is different, but I have no intention to copy the Windows behavior into my application (it is meant to be Linux-Windows cross-platform anyway, so Windows isn't the dominating factor).

In this special case (Console) consider the following scenario: You are typing something into the console, but notice, that you need some information from previous console output to complete the instruction, so you have to scroll up. After that you will have to continue to type in the rest of the instruction

If dragging can only be done with active widgets, I guess it would be better to keep it as it is. After all it is only a minor annoyance and probably not worth putting a huge amount of work into fixing it.

Yah, sorry it wouldn't be an easy change:


// See if we should be dragging a widget.
if( (mActiveWidget->getGrabbed()) && (mActiveWidget->draggingEnabled()) )
{
mDraggingWidget = true;

// Dragging, which uses move function, works with pixel values (uninfluenced by parent dimensions!)
mActiveWidget->drag(xPixelOffset,yPixelOffset);

return true;
}


This is in the injectMouseMove function. So mouse down would set the active widget and grab it, and when moving the mouse, I see if the active widget can be dragged, and if so, drag it.