I want to detect CompositeTransform's TranslateY of ListBox. For this it's necessary to set the ListBox ScrollViewer.ManipulationMode="Control".
However, it causes lag when the listbox is dragged. How to avoid this?
I'll recommend you read following article on ScrollViewer performance.
The MSDN remarks for ScrollViewer.ManipulationMode says
In Windows Phone OS 7.1, the ManipulationMode property enables you to
specify how most of the property updates and events associated with
scrolling a ScrollViewer are handled. You can specify that the system
will handle the manipulations or that you will handle the
manipulations at the control level. In most cases, to ensure smooth
scrolling, you should let the system handle the manipulations, which
is the default behavior.
As you can see, it's unlikely you'll be able to get smooth scrolling and virtualization, when setting the ManipulationMode. What precisely do you need the TranslateY value for?
Related
My VB.Net application is using anchoring to force certain controls to resize to their container, eg a list box on a form. This is all pretty standard and easy to do. However having just released the application into production I've found that on one user's computer the anchoring seems to just be ignored. She has Windows 7, as do I.
So far example what should look like this:
instead looks like this
I asked her to try a higher resolution on her screen but that didn't to help.
On one of them I was able to fix it by manually setting the width and height in form load properties of the control instead of anchoring it, but it seems a bit backward.
It looks to me like the form has been resized to be too small for the anchoring to work correctly. Set the .MinimumSize property of the form to ensure the form does not get too small for your layout.
Older staff sometimes reduce the screen dpi to make text easier to read, which means the screen may not be big enough to display the form. To fix this, set the screen dpi back to something reasonable and increase the text size for readability.
Turned out to be that the display issues were caused by user having the "Font Size" setting on her computer set to 200%. To be honest I didn't even know you could do that.
I have a large problem disabling a slider in LabVIEW. Here is my minimal example:
I have a simple Slider, which is disabled and grayed out if the value is higher than 5. Otherwise the Slider is enabled.
If I drag the slider higher than 5, the Slider gets grayed out. But I am still able to move the slider around and change the value. Only after I dropped the Slider, the Slider is disabled to use.
In my opinion, this is a large bug of LabVIEW. Is there any way to disable the Slider correct during drag?
Thank you for your answers!
Additional information:
Like I said, the snippet is only my minimal example to show the basic problem. In my application the following is happening:
I have s statemachine with a state that enables the Slider and a state that disables my Slider. The state can change every moment, so it´s possible, the user is using the slider at the moment of statechange --> moment of disabling. At this moment the slider should be disabled (it only gets grayed out) directly ... not after releasing it. So limiting the maximum is not real target. I want to prohibit all slider actions for a user.
"Link to question asked on NI Discussion Forums"
As suggested by Alexander_Sobolev on the NI forum (but I promise I thought of it independently!), you can end the slider drag by generating a mouse up event. On Windows you can do this with Simulate Mouse.vi from the NI site, which calls mouse_event from user32.dll:
Note that one of that VI's mouse position inputs is erroneously marked as 'Required'; I fixed that before creating the code above.
I do think this is a UI technique that should only be used if it's really justified by the requirements of the system, and if the users will understand why it works like that; otherwise it could make for a frustrating and annoying user experience. I don't think it's a bug, rather a design decision, because the opposite behaviour could be equally undesired in other circumstances.
I guess you could set the slider value to 5 inside the case structure, alongside the greying out, by adding another property node. This should keep the slider stuck at 5, if the user tries to pull it above.
This appears to be strange behavior as the Value Change event is triggered while the mouse button is held down even when the control is Disabled & Grayed Out.
One way I can think of to limit the value would be to update the Data Entry Limits Maximum property for this control and setting the Response to Value Outside Limits for Maximum to be Coerce.
I created a winform application. The size of each screen is 1361, 768 in pixels. This worked great for larger screens and/or laptops. But now I have to move my application to 10inch screen tablets, which means my application does not fit.
I have never had to deal with this issue before, how can auto adjust each form size and adjust all of the controls and panels when viewing on smaller screens?
I am using VS 2012.
Making forms fully scalable in WinForms is possible, but it takes a bit of work. The good news is that most of this work is done at design-time, arranging the controls properly so that everything is done for you automatically by the framework. It's drudgery, but it isn't difficult. Rejoice that you don't have to write the scaling code by hand, form-by-form, like you did with VB 6.
There are four fundamental properties that you will need to acquaint yourself with:
Anchor
Dock
Margin
Padding
The last two should be quite familiar web developers who know CSS—they do the same thing here. Padding controls the inner margin around a control, while margin controls the outer margin. You will need to set these correctly to ensure that your controls can "breathe", because the automatic scaling code is just going to jam them up against one another.
The "standard" margins around a control in a Windows desktop application are approximately 12–15 pixels. You should make sure that you leave at least this much room. Then add additional margins/padding as you see fit to separate things. I keep these layout specifications bookmarked for reference. This is another good reference.
The next step is to instruct the layout manager how you want the controls to be arranged and resized. The key to this is to think in terms of container controls and child controls. The form itself is a container control, and you can set its child controls to either Anchor or Dock within its boundaries. One or more of those child controls can itself be a container control, and its child controls can be Anchored or Docked within its borders. The nesting is virtually unlimited, but for your own sanity and reasonable redraw performance, you'll want to keep it to a reasonable minimum.
A good way of doing this is to use the two provided invisible layout helpers, FlowLayoutPanel and TableLayoutPanel. Personally, I don't find the former very useful very often, at least not for standard Windows applications. But the TableLayoutPanel is invaluable.
Generally what I will do is fill my entire form with a TableLayoutPanel (margins = 0, dock = fill). Then I will add individual controls (or sometimes another nested TableLayoutPanel) to its cells. Those child controls will have their margins set appropriately, and will have either their Anchor or Dock properties set, depending on whether I want that control to have a fixed size or resize dynamically.
Before you get the hang of how these properties interact and how it all works, you'll probably need to play around with your layout a bit. Make a backup of your forms and then just dig in. Or, you might find it easier to start designing each form from scratch (you can still copy-and-paste individual controls in order to preserve their other properties). Eventually, it will all start making sense to you, and you'll be up and going in a jiffy.
The great thing is, once this is all set up, all you have to do is ensure that your form is resizable. Then, whether the user manually resizes it or uses the maximize/restore button, it'll automatically fill their screen size. This also works well for all DPI settings, which is another common Achilles' heel of WinForms devs.
Try to get the resolutions variables to adjust your screens, there is an answer to get these variables using the Screen class
Getting Screen Resolution
DevExpress has a great control call the Layout Control. This control helps to maintain consistent whitespace between controls as the form is resized. It does take a little study to use the control effectively but once you understand how to use this control the results are consistent and you are able to speed through form design.
The documentation for HBox and VBox includes the statement:
Deprecated: Use Box instead, which is a very quick and easy change.
But we recommend switching to Grid, since Box will go away eventually.
However, it isn't obvious what the "quick and easy change" should be.
How do you use Box and/or Grid to achieve the functionality of VBox or HBox?
One of the big changes in gtkmm3:
Gtk::Box, Gtk::ButtonBox, Gtk::IconView, Gtk::Paned, Gtk::ProgressBar,
Gtk::ScaleButton, Gtk::ScrollBar and Gtk::Separator now derive from
Gtk::Orientable, allowing their orientation (vertical or horizontal)
to be specified without requiring the use of a derived class such as
Gtk::HBox.
Although Grid isn't mentioned above, both containers now have a method set_orientation; Box can also take it in the constructor. So for Box, set the orientation and use your usual pack_start, pack_end.
With Grid, if you scrutinize the documentation, you'll see this line:
Grid can be used like a Box by just using Gtk::Container::add(), which
will place children next to each other in the direction determined by
the orientation property.
So, it should be as simple as setting the orientation and then add your child widgets.
I have created a Windows 8 Store App using C# / XAML. My interface includes a scrollable list, which is rendered using an ScrollViewer. I would like to be able to handle manipulation events on the elements within the list, however, setting ManipulationMode to anything other than None on the list element causes my list to no longer scroll.
Here is a simplified version of the UI:
<ScrollViewer>
<Border/> <!-- these contain child content -->
<Border/>
<Border/>
<!-- Set ManipulationMode on an element in order to receive manipulation events -->
<!-- This causes the scroll viewer to stop working! -->
<Border ManipulationMode="All"
ManipulationDelta="..."/>
<Border/>
<Border/>
</ScrollViewer>
I understand that the WinRT ScrollViewer uses a special ManipulationMode of System for performance reasons, but I would like to have a vertically scrolling list, containing elements that respond to horizontal manipulation / gestures. Can anyone think of a creative workaround that would make this possible?
it may be long time but didn't find any good solution. I just achieved what I wanted very easily.
public MovableGrid()
{
ManipulationMode = ManipulationModes.TranslateX | ManipulationModes.System;
AddHandler(ManipulationDeltaEvent, new ManipulationDeltaEventHandler(UIElement_OnManipulationDelta), true);
AddHandler(ManipulationCompletedEvent, new ManipulationCompletedEventHandler(UIElement_OnManipulationCompleted), true);
}
I wanted my MovableGrid to be moved on X axis and I have list of MovableGrids which I wanted to be scrolled with scrollviewer. That's enough to do that.
What I have done was I put a transparent rectangle on top of the ScrollViewer and handle manipulations there. When I find the manipulation should scroll the ScrollViewer - I scroll the ScrollViewer using the ScrollToHorizontal/VerticalOffset() methods. On ManipulationStarted I also use VisualTreeHelper.FindElementsInHostCoordinates to check which item I could manipulate too and then I can decide whether to manipulate that item or not depending on various conditions. It's quite a bit of custom code though. You would also need to update the RenderTransform of the ScrollContentPresenter in the ScrollViewer when the user tries to drag farther than minimum/maximum offset to immitate the ScrollViewer default behavior, handle mouse scrollwheel etc. Nothing YOU could not handle of course. I could not find a better way unfortunately and I am interested if someone finds one.
EDIT* Another solution I thought of when trying to answer another similar question was to use another ScrollViewer as a child item and use its ViewChanged events instead of manipulation events.
EDIT 2*
Also with Windows 8.1 you get ManipulationModes.System which combined with other modes should allow you to handle manipulations inside of a ScrollViewer. Then you can call CancelDirectManipulations() on the manipulated element once you want its parent ScrollViewers to stop processing manipulations for pan&zoom.