I have a simple slider, with only 3 options. It seems strange to force the user to drag the small thumbnail on the slider, when it would be a lot easier to click one of the 3 actual labels by the side of the slider. Does anyone know how to accomplish this?
This is a cool problem.
The Label object used by Slider turns out to be a subclass of Label (called SliderLabel). So, probably the best approach would be to subclass Slider and add event listeners to the labels.
I think you could successfully add event listeners in either the commitProperties method or the updateDisplayList method. I'm not sure if one would be preferable to the other, but commitProperties seems like the more correct choice.
So, in your subclass of Slider:
override protected function commitProperties():void
{
super.commitProperties();
for(var i:int = 0; i < labelObjects.numChildren; i++)
{
if(!SliderLabel(labelObjects.getChildAt(i)).hasEventListener(MouseEvent.CLICK))
{
SliderLabel(labelObjects.getChildAt(i)).addEventListener(MouseEvent.CLICK,sliderLabelClickListener);
}
}
}
and then maybe something like this for sliderLabelClickListener:
private function sliderLabelClickListener(e:MouseEvent):void
{
dispatchEvent( new SliderLabelClickEvent(e.target) );
}
I think you'd want a custom event there, rather than dispatching a regular Event, so you could include the name/id/value of the label.
Also, you may want to put in a 'dispose' method to remove the CLICK event listener from the labels when the Slider is removed from the stage. It's not an issue if you aren't going to be removing the Slider, but if you are, what I normally do is create a method called dispose and put all my manual removal logic there (removing event listeners, unwatching/removing ChangeWatchers). Then I assign a listener to the component's REMOVED_FROM_STAGE event and call the dispose method from that listener.
Are you sure a slider is the best component to use in this case? Generally speaking, sliders are to be used when the user has a large range of contiguous options to choose from, where the precision of a user's choice doesn't really matter (e.g. a volume slider - having volume at 51% as opposed to 50% really won't make much of a difference).
If you only have three options, and the user is only allowed to select one of those three options, I would suggest using either a combo box or a radio button group.
Related
I'm trying to implement an NSSplitView similar to Xcode where you can collapse a view by dragging its handle to under half its width and it will collapse automatically. I have that part working, but I need to update the state of a button in the toolbar when this happens. I tried listening to splitViewDidResizeSubviews and checking if the splitView's view is collapsed, but that method fires 16 times with collapsed == true, so I don't think I want to update the button's state 16 times. Is there a cleaner way to do this? I'm new to Cocoa, but from what I've seen, I would expect there to be some way to just say bind this button's state to the isCollapsed property and be done with it. Does such a thing exist?
If you subclass your NSSplitViewController you can add a listener for the SplitViewItem's isCollapsed property:
class MySplitViewController: NSSplitViewController {
var observer: NSKeyValueObservation?
override func viewDidLoad() {
super.viewDidLoad()
// Do view setup here.
let sideViewSplitViewItem = splitViewItems[0]
observer = sideViewSplitViewItem.observe(\.isCollapsed, options: [.initial, .new]) {splitViewItem, _ in
print("Sidebar collapsed state changed to: \(splitViewItem.isCollapsed)")
}
}
}
The best way to see what bindings are available is to check the docs, specifically the Cocoa Bindings Reference (look in the sidebar for the view you're after).
NSSplitView doesn't have the binding you describe, so I think you're on the right track with your current approach. Of course, you don't need to update the button's state sixteen times, just check it's value each time, and update it if needs be. It might seem a bit wasteful, but checking the value of a bool is a very cheap operation, and you won't notice any kind of performance hit.
While NSSplitView has no event or observable property for when one of it's subviews is "collapsed", the immediate subview itself will have its hidden property set to YES.
So you can either observe the subview's hidden property yourself, or if you're creating your own custom subview of NSView, you can override the -(void) setHidden:(BOOL)hidden to catch the event.
I do the latter, and it works correctly every time.
-(void)setHidden:(BOOL)hidden
{
[super setHidden:hidden];
// Insert code to react to the "collapsed" event here.
// (You're likely going to tell your parent view,
// self.window.windowController, or something.)
}
Of course the setHidden method / hidden property can in theory be called for purposes other than from NSSplitView "collapsing" your view, but this is very unlikely to ever happen in practice.
I have created my own custom drawn list with checkboxesin WTL, I want to make it scrollable now, the thing is that I am subclassing a Static Text control over which I draw.. And I don't know if static controls support scrolling in any way..
Anyway my question is how do I make my custom made controll scrollable, do I have to impement the mechanism myself?
Yes, you'll have to implement it entirely by hand. That's the drawback of not using a built-in control. It probably would have been a better idea to start off with a ListBox and then customize that to your desire. That way, you would get all of the scrolling, selection, and other logic for free.
The steps are roughly as follows (there are probably ATL/WTL idioms for some or all of these, but any ATL/WTL programmer can convert back and forth from raw Win32):
Add the WS_HSCROLL and/or WS_VSCROLL window styles to your custom static control, depending on if you want a horizontal, vertical, or both scroll bars. You would add these to list of window styles passed in to the CreateWindow/CreateWindowEx function.
By default, those scroll bars won't do anything at all. You need to tell them what to do using the SetScrollInfo function. In your case:
The first parameter (hwnd) would be the handle to your control window.
The second parameter (fnBar) should be either SB_HORZ to adjust the horizontal scroll bar, or SB_VERT to adjust the vertical scroll bar.
The third parameter (lpsi) is a pointer to a SCROLLINFO structure, filled in with the desired scrolling parameters, including the current position of the thumb, the minimum and maximum values, and the "page" size used to set up the proportional scroll bar.
The fourth parameter (fRedraw) should probably be set to TRUE.
You will also need the EnableScrollBar function to enable/disable the scroll bar as appropriate. Like the previous function,
hwnd is a handle to your control window
wSBflags is either SB_HORZ, SB_VERT, or SB_BOTH
wArrows is one of the ESB_* values, depending on what you want
Finally, you will want to write code in your custom control's window procedure to handle the WM_HSCROLL and/or WM_VSCROLL messages. These are sent to the window whenever the scroll bar is moved. Inside of the handler for these messages, you will want to do the following things to update the control's state:
Call the SetScrollInfo function to update the thumb to its new position
Redraw the contents of your control in accordance with the scrolled distance. There are multiple ways of doing this, but I'd probably use the ScrollWindowEx function.
The custom control's window procedure will also need to handle the WM_SIZE message to update the scroll bar state (by calling SetScrollInfo and/or EnableScrollBar) in response to changes in the window's size.
Cody Gray provided excellent introduction into adding support for scrolling, however what you also have is the help from the WTL itself.
WTL's atlscrl.h offers you classes to inherit from and implement a custom window/control with scrolling.
// Classes in this file:
//
// CScrollImpl<T>
// CScrollWindowImpl<T, TBase, TWinTraits>
// CMapScrollImpl<T>
// CMapScrollWindowImpl<T, TBase, TWinTraits>
// CFSBWindowT<TBase>
// CZoomScrollImpl<T>
// CZoomScrollWindowImpl<T, TBase, TWinTraits>
// CScrollContainerImpl<T, TBase, TWinTraits>
// CScrollContainer
Not so much code/snippets around to demo the use, but there is still one WTL sample that covers the basics and it should be a good starting point for you as well. \Samples\BmpView has a class for scrollable bitmap:
class CBitmapView :
public CScrollWindowImpl<CBitmapView>
{
public:
You will see it's really small and it covers most of the complexity.
I am new to Windows Phone Programming. In my application, I Have a listbox which lists the phone contacts. Currently it is listed as a regular list with equal size for list items in the UI.I am looking to modify the front end like this :
I dont want to have different sizes /back ground color for each list items rather a fixed UI and let the lists scroll through it and the list item in the view, at any time, should be displayed as in the picture.
I dont expect any codes as answers but any examples are welcome too, just want to know using what feature this kind of functionality is possible so that i can do my reading!
Thanks,
Deepak
It would be difficult to modify an existing control (ListBox for example) to act like this, so your best bet would probably be an ItemsControl with its RenderTransform set as a TranslateTransform.
If you place a Rectangle (with Fill="Transparent") over the ItemsControl, you can attach handlers to the ManipulationStarted, ManipulationDelta, and ManipulationCompleted events to control the "scrolling" by setting the TranslateTransform's Y offset.
To resize the items in the list there are two options: a custom panel or manual setting.
Custom Panel
You could create a custom Panel implementation that will appropriately resize its Children based on a property you would create to represent the scroll position. Set the ItemsControl to use your panel, and either through binding or attaching a handler to the panel's Loaded event and keeping a pointer to the panel, update the aforementioned property from inside the ManipulationDelta handler.
Manual Setting
From inside of the ManipulationDelta handler, you can also calculate the various heights of the boxes and use MyItemsControl.ItemContainerGenerator.ContainerFromIndex to get the visual for each item and set its height.
I would suggest putting this all inside of a custom UserControl.
You may have issues with clipping using the TranslateTransform but hopefully this will get you started. Unfortunately, this looks like a rather difficult control to try making as your first windows phone project!
So Finally I did manage to find a way to do it.
First approach was as #Murkaeus suggested, Using UserControl and ManipulationDelta event handler. However for some reason the manipulationDelta event was triggered only for 2 finger gestures (Zoom, Pinch..etc), I have no clue why. And after some trying I had to give up on this.
The next approach was using Listbox itself. The source of the Listbox was set as the List( of Models objects) that I create after reading the contact information from phone. The height and color of the listbox item was bound to a property in my model named "scaleLevel" and was accordingly converted by implementing IValueConvertors to give predefined color and height values for different scale levels.
I created an attached property for the scrollviewer vertical offset like mentioned [here] (http://www.scottlogic.co.uk/blog/colin/2010/07/exposing-and-binding-to-a-silverlight-scrollviewer%E2%80%99s-scrollbars/)!
This event is triggered on change of the vertical offset and every time there is a scroll, I find out which listbox item to be enlarged and which reduced based current vertical offset.
Once I have this information, I change the property ("scaleLevel") of the affected items in the List (of Model) (which is bound to listbox height and color). This change is updated in UI using the INotifyPropertyChanged Event.
I have no idea if this the best way of doing it , but it works well and there is no considerable in updating the UI despite the processing involved.
I would like to hear your opinion about the implementation and any other solution which you feel will work better.
I need to fire a method when a figure is selected in GEF diagram.
addSelectionChangedListener works well when I select a figure, but if i click on the same figure again ("unselect") the listener doesn't fire.
How can i fix it?
final GraphicalViewer viewer = new ScrollingGraphicalViewer();
viewer.addSelectionChangedListener(new ISelectionChangedListener() {
public void selectionChanged(SelectionChangedEvent event) {
//Fired when figure is selected, but not when same figure is selected again
}
});
I don't think you can implement a toggling behaviour for a GEF figure through the selection mechanism. The selectionChanged event gets fired when the selection changes, so clicking twice on the same figure is not going to make it.
Maybe a different approach is needed taking into consideration that a figure is deselected when another figure gets selected and that you can retrieve the that element from the SelectionChangedEvent object passed in.
Also, you should only care about the user selecting a figure within the diagram and not a different element from any other workbench part.
I'm trying to make the cells of a QTableView look like 3D clickable buttons. So that when you click on a cell, the button looks pushed. Everyone seems to think I merely want to change the colour, I need to show images of a normal button, and a pushed button, that look 3-dimensional.
I have done this already with calling QTableView::setItemDelegate(), with an appropriate ItemDelegate that will change the background of the cell when it's clicked. However I'm stuck at this point because I want some cells to be different coloured buttons based on the data they contain. So a cell with a low number would be a red button, that's also red when it's clicked, and the other cells would be different colours.
I can set the colour of the button with the TableModel, but once the button is clicked, there is no way for the ItemDelegate to know that it's supposed to be a different colour than the rest. How can you link the two so the ItemDelegate knows what colour it's supposed to be?
Also, is there simply a better way to make cells look like buttons?
You can call QModelIndex::model() from within the ItemDelegate's paint() method, since it has a QModelIndex parameter. This gives you the TableModel for the data, which you can programatically decide what colour the cell's button will be.
However, this is still not as elegant as I'd hope. Does anyone know a better way to change the appearance of table cells when in both the up and down button push states?
Why don't you asked the index for the background color.
Something like this ...
QStyleOptionToolButton buttonOption;
const QStyleOptionViewItemV4& optionV4 = dynamic_cast<QStyleOptionViewItemV4&>(option);
//...
buttonOption.palette.setBrush( QPalette::Button, index.data( Qt::BackgroundColorRole ) );
//...
I have feeling that its a bug in Qt and its must have been ...
// model code
if(role==Qt::BackgroundColorRole )
return qvariant_cast<QBrush>( QBrush(Qt::red) );
// delegate code
buttonOption.palette.setBrush(QPalette::Button, optionV4.backgroundBrush );
Because the optionV4.backgroundBrush is correct in the sizeHint method but is invalid in the paint method . I see now reason why the sizeHint should have the background brush and the paint method not. I'll report it to Nokia.
EDIT:
Looks like I was right and its a bug in < Qt4.5.
QStyleOptionViewItemV4 doesn't copy the icon and backgroundBrush
Can you not get the ID/row count of the table cell's row and then check it against the colour table that you may be having, and set the colour accordingly? I am not sure if I understood your question well or not.
Assign a data role for the background color, and in your item delegate, ask the model index what it's background color is (using data( bg_color_role ) or something similar). Then, in your model, you need to make sure the data function returns a color for the bg_color_role that is appropriate for the data being modeled.
The way to do that is to use the data method of the QModelIndex object you get on the paint method, and ask for a specific role (if you define a custom model, you can add your own roles, and give the information you need to the delegate in those roles.)
TimW, I think you have to fill the QStyleOptionViewItemV4 info by calling initStyleOption before.
I'm not sure where the requirement for a background image comes from. If you want the cells to look like QPushButtons, you should probably inherit from QItemDelegate and implement paint() to use QStyle to draw you a QPushButton, something like this:
QStyleOptionButton opt;
// fill 'opt' from the information from the model, and the style option that's passed in
style()->drawControl( QStyle::CE_PushButton, &opt, painter );
Have you tried using custom style sheets?
You could just apply the same stylesheet to every cell, and then change the background image / style to draw the 3D button images depending on whether or not it's selected.