Within an UWP-App containing a MapControl, is there a way to distinct between a manipulation to the map made by the user (e.g. by pinch to zoom) and one, that is made by the app itself? (e.g. by calling mapControl.TrySetViewAsync(...))
It doesn't seem like that there's an eventhandler for that, right?
I already tried several ones (like LoadingStatusChanged or CenterChanged), but none of them are making any difference between user- and app-manipulation..
You should be able to register to receive a TargetCameraChanged event that will fire whenever the map view changes. The MapTargetCameraChangedEventArgs returned contain a ChangeReason property.
The ChangeReason property will be System, UserInteraction or Programmatic.
Map movements caused by calling APIs such as TrySetViewAsync(...) cause events that have ChangeReason == Programmatic, and movements caused by user actions such as pinch to zoom should have ChangeReason == UserInteraction.
Related
Is it possible (e.g. by overwriting a prototype) to filter (enable/disable) events globally in KONVA?
use case:
I have an interactive app built with KONVA. At the beginning, I want to show a "demonstration" of the user interface: I'm displaying a moving second mouse cursor and fire events which are handled by the app to demonstrate possible interactions. All is working, but during the demonstration, the app should not listen to real mouse events, only to the simulated ones (having a special property set in event object).
For that use case, just set listening: false for your stage. It will disable ALL events on the stage and its children.
You can turn off events just for demonstration. As soon as it is done, you can turn mouse/touch/pointers events on with listening: true.
I'm trying to work out how to catch a data binding in the act (either intercept or post-process) to customize the display of data in the target control.
I know about IValueConvertor and understand that I can transform a simple value into another simple value, but I don't believe this is enough for my needs... which are:
The control in this case is a TextBlock and the data values from the objects in my ObservableCollection are variable length strings. I want to render the strings in multiple colours by splitting them into pieces and programatically creating a <Run Foreground="xxx" Text="yyy"/> for each piece inside the TextBlock.
Since the strings are variable length and the colours have to be programatically determined from the content of the string, I don't believe I can pre-create the <Run>s in the XAML, so I have to somehow get in on the data binding action and generate the <Run>s at bind-time (or very soon after).
Binding.NotifyOnTargetUpdated would seem to be a way to set up an event handler to do the work, but that's not available in the Windows Phone cut-down Silverlight implementation.
Any ideas? All search results seem to point to the above, but I'm looking for that little bit more.
Having apparently exhausted all the cut-down Silverlight on Windows Phone options for programmatically hooking the rendering of ListBoxItems via the data model, I ended up adding a Loaded="..." event handler to the XAML for the TextBlock.
It doesn't feel like the nicest solution, but perhaps that's just my code-preference talking and it's actually the right way to do it on Windows Phone.
In any case, because I'm hooked to the TextBlock directly, I'm not sure how to then get to the databound object on the ListBoxItem containing the TextBlock... if anyone has advice on how to get back up the tree to the generated ListBoxItem then I could use the bound object directly instead of retrieving it from elsewhere.
Note that since the ListBoxItem is generated, I didn't find where to put a Loaded="..." event handler for that in the XAML. The ListBox.ItemTemplate doesn't accept a Loaded attribute.
Update: this doesn't work!
The Loaded event handler fires when the TextBlock is first created and loaded, so the substitution works initially.
BUT
The generated ListBoxItem seems to be recycled (I guess by the ListBox.ItemContainerGenerator which doesn't want to use excessive amounts of memory by instantiating a whole new container when there are many off-screen entries in the list that won't need to be seen for a while) and when this happens, the Loaded event DOES NOT FIRE.
Since I modify the content when the TextBlock was first Loaded, this breaks the binding association so when the ListBoxItem is recycled, it now contains old/incorrect data.
Still no solution.
I'm thinking about trying to use an IValueConvertor and somehow pass a reference to the binding target... now sure how yet though.
Update 2: finally got it to work...
Sticking with the Loaded="..." event handler, it is possible to disable recycling of previously-generated ListBoxItems by configuring the VirtualizingStackPanel used by the ListBox under the covers.
In the XAML for the ListBox set VirtualizingStackPanel.VirtualizationMode="Standard" to force a new ListBoxItem to be generated each time instead of recycling previously-generated ones.
This means the Loaded event handler is called every time and I can replace the ordinary text of the TextBlock with the <Run>s to produce dynamically coloured text.
I have developed an extension for Safari which uses a context menu.
In the code, I am listening to the command event of the context menu item using:
safari.application.addEventListener("command", commandHandler, false);
In the commandHandler() function, I have added an alert statement for debugging purposes. By doing so, I found that the function commandHandler() is firing twice whenever I click on the context menu item.
Also I added a tool bar item, which also fires the command() event on clicking. The function attached to the command() event is also firing twice after clicking on the item.
Does anybody know of this issue and how to resolve it?
Without more information, this sounds like a problem of insufficient filtering. That is, you're receiving all command messages without determining which they are or why they're flowing across your callback layer, and your callback layer receives two messages per click of, as given, unknown disposition.
The event notification callback structure for Safari extensions allows you to register multiple events against the same event type, and multiple distinct events may be generated in many cases. To this end, your attempt to add an event listener to the "command" scope means you're literally receiving all commands passed to the callback layer. These may be multi-firing in cases where you have, for example, a complex nesting relationship (A contains B, where A and B both notify) or a complex behavior pattern (for example, a mousedown followed by a mouseup).
Apple provides guidance on how to handle this scenario, by binding the command to a specific target or specific command, which is what you should do here. And just in case that's insufficient, here's additional documentation on how the callback system works to help you define your events properly.
Following the guidance should allow you to work through this issue by properly binding your events to your object and only operating on the events you need. Everything else should simply be ignored by your event handler.
I need to capture the event that an app throws when you click on the screen, on a list. When I click on the screen, actionPerformeed(ActionEvent e) returns -1, I suppose that it is the default event.
In non-touch devices, the launched event by pressing the central button is Canvas.FIRE, why not in tactile devices?
How can I do that?
The actionEvent source argument will be from the list. Action events are designed to encapsulate the trigger for the action (e.g. key/touch) since that is irrelevant. There is no need to distinguish the trigger since you can always extract the lists selected item and use that.
There are use cases where one would like to know the location touched within the cell renderer but that is a special case unrelated to the question.
New to GWT here...
I'm using the UIBinder approach to layout an app, somewhat in the style of the GWT Mail sample. The app starts with a DockLayoutPanel added to RootLayoutPanel within the onModuleLoad() method. The DockLayoutPanel has a static North and a static South, using a custom center widget defined like:
public class BigLayoutWidget extends ResizeComposite {
...
}
This custom widget is laid out using BigLayoutWidget.ui.xml, which in turn consists of a TabLayoutPanel (3 tabs), the first of which contains a SplitLayoutPanel divided into WEST (Shortcuts.ui.xml) and CENTER (Workpanel.ui.xml). Shortcuts, in turn, consists of a StackLayoutPanel with 3 stacks, each defined in its own ui.xml file.
I want click events within one of Shortcuts' individual stacks to change the contents of Workpanel, but so far I've only been able to manipulate widgets within the same class. Using the simplest case, I can't get a button click w/in Shortcuts to clear the contents of Workpanel or make WorkPanel non-visible.
A few questions...
Is ResizeComposite the right type of class to extend for this? I'm following the approach from the Mail example for TopPanel, MailList, etc, so maybe not?
How can I make these clicks manipulate the contents of panels in which they do NOT reside?
Are listeners no longer recommended for handling events? I thought I saw somewhere during compilation that ClickHandlers are used these days, and the click listener "subscription" approach is being deprecated (I'm mostly using #UiHandler annotations)
Is there an easy way to get a handle to specific elements in my app/page? (Applying the "ID" field in the UI.XML file generates a deprecation warning). I'm looking for something like a document.getElementById() that get me a handle to specific elements. If that exists, how do I set the handle/ID on the element, and how can I then call that element by name/id?
Note that I have the layout itself pretty well nailed; it's the interaction from one ui.xml modularized panel to the next that I can't quite get.
Thanks in advance.
If you don't have a use for resizing events than just use Composite
What you want is what the GWT devs called message bus (implemented as HandlerManager). You can get a nice explanation in the widely discussed (for example, on the GWT Google Group, just search for 'mvp') presentation by Ray Ryan from Google I/O 2009 which can be found here. Basically, you "broadcast" an event on that message bus and then a Widget listening for that event gets the message and does its stuff.
Yep, *Handlers are the current way of handling events - the usage is basically the same so migration shouldn't be a problem (docs). They changed it so that they could introduce custom fields in the future, without breaking existing code.
If you've set an id for any DOM element (for Widgets I use someWidget.getElement().setId(id), usually in combination with DOM.createUniqueId()) you can get it via GWT.get(String id). You'll get then a RootPanel which you'll have to cast to the right Widget class - as you can see it can get a little 'hackish' (what if you change the type of the Widget by that id? Exceptions, or worse), so I'd recommend sticking with MVP (see the first point) and communicating via the message bus. Remember however, that sometimes it's also good to aggregate - not everything has to be handled via the message bus :)
Bottom line is I'd recommend embracing MVP (and History) as soon as possible - it makes GWT development much easier and less messy :) (I know from experience, that with time the code starts to look like a nightmare, if you don't divide it into presentation, view, etc.)