I need on my form ordinary widgets (e.g. buttons) do not react on mouse clicks but NOT to be disabled (it change look to grayed one -- not good).
I wonder is there some neat small hack for this?
You could stick in an event filter and filter out the mouse events before passing the remaining events on for processing, but I'm not sure that not giving the user a visual clue that certain elements are effectively disabled is such a good idea.
You could try using style sheets to control how the disabled mode of the buttons in your form get styled. Unfortunately I'm not sure exactly how to do that but you could have a look at the style sheet docs to get you started.
Related
So I am having this issue with using Google VR reticle where I cannot click a button. I have an image attached showing the heirarchy and the PlayButton is what I am trying to click. The Canvas has a Graphic Raycaster, the button has an Event Trigger that calls the method to navigate to the next scene. The UpScrollPanel, and DownScrollPanel work just fine. The EventSystem has the Gaze Input Module, as well as Event System, and Touch Input Module.
Any ideas on how to get this working? I have watched a few videos from NurFACEGAMES and while they helped a little, I haven't gotten the click to work yet.
Oh, and I am using Unity 5.3.4f
Sometimes things can get in the way of the button, make sure that no other UI elements overlap it, for example text borders (which are actually larger than they appear). You can also fix this by moving the button up the hierarchy among its siblings, I believe the first child is top.
Also try moving the button up the hierarchy if possible, sometimes UI having certain parents makes them not work
The canvas object should have a graphic raycaster
I found the issue to be unrelated to anything I thought it was. The menu I was using is a prefab I also use in another view that isn't VR. The scrollrect was loading that prefab, instead of the modified one I was using in the VR menu, and therefore the triggers I had added to the button were no being used when the app loaded.
I was wondering if there was a way to modify the panel behind the buttons? I need to change the color. Also is there a way to remove the CANCEL button on the finish page?
Removing the cancel button is such a user experience no-no that you should really reconsider it. If you insist on doing potentially the wrong thing:
wizard->setOption(QWizard::NoCancelButton);
You can call it from a reimplementation of QWizardPage::initializePage, that way it will remove the button as the page is being shown.
You can use the style sheets to customize the look of your panel. You can also manually change its pallette.
I apologize if the title was not clear enough. I am working on a project where a user can design a page (something like Wix). I am continuing on a project left in-complete by some developer. The sequence of action is.
The user clicks on a link which adds an element on the page (e.g. textElement, picture, slider...)
There is an edit button for each element. Clicking which opens a dialog box.
On the dialog box there are sliders and color picker drawn using Kendo-UI. Using them the user can change the style settings for the element (e.g Font-Color, BG-Color, Font Size...)
What I want now is to apply/show the changes live on that element. I have the id available for each element. I can bind each of the style selectors and apply the changes live to the text element. But that does not seem the right choice as in future we might add another style selector in the dialog box, and that would mean adding the code for binding this new selector.
What I wanted to know was that is there an alternate or preferably easy way to do this?
Regards
Share some code with the basic idea that you follow, cause it's not getting clear what you did. It sounds like you can use the MVVM framework feature to help you for that.
I have two options. I need 48 of a certain type control; it needs to respond to clicks and taps (for touch devices).
I could use Buttons, using the TextButtonStyle, and the Click event. Or I could use TextBlock, with the Tapped event.
I reckon buttons may be more "expensive" to create. OTOH, although I believe "Tapped" is also called when the user clicks the component, this makes me a little nervous due to its nomenclature, I guess.
Another difference is that a button takes up only the width necessary, whereas a TextBlock takes everything; and I want the underlying Grid to be tappable, so the TextBlock is kind of a problem that way. Is there a property that will make it more modest like the button?
There is design guidance for Windows Store apps on when and how to use buttons at http://msdn.microsoft.com/en-US/library/windows/apps/hh465470. Based on your description and this guidance, it sounds like buttons are the way to go. Responding to click events is what they were made for, and TextBlocks add the extra issues that you describe.
I'm using Qt with C++, and I want to make a button that keeps looking pushed down after it is pushed and released. I'm currently making buttons on a QToolBar and doing something like toolBar->addAction (icon, tr("Text"));. This makes buttons on the toolbar that display the QIcon named icon and display "Text" on hover-over. They also look pushed down as the user is pushing them, but stop looking pushed down when they are released (as is reasonable for most uses of buttons). I need something different, however: I would simply like the buttons to remain looking pushed down after they are released, perhaps until they are clicked again. It would be best if I could just call some function on a button or on the toolbar that could give me the capacity to control whether a button will look pushed down or not pushed down when it is displayed. That way I could just control this aspect of button appearance programmatically.
What's the easiest way to do this in Qt? I've seen fancy ways of doing it involving borders and very complicated setups, but I was wondering whether there might be an easy way to do it.
Add QPushButton to the toolbar using addWidget and then make the button checkable.