I would like to dispatch my onPressed event to subsequent objects in my QML tree, (I have indicate mouse.accepted = false and propagateComposedEvents: true ) but I want to keep the onreleased event working on the top level element ..
Here the code :
Item {
width: 200
height: 200
Rectangle {
z: 1
anchors.fill: parent
MouseArea{
anchors.fill: parent
propagateComposedEvents: true
onPressed: {
console.log("R1 pressed")
mouse.accepted = false
}
onReleased: {
console.log("R1 released")
mouse.accepted = false
}
}
}
Rectangle {
z: 0
anchors.fill: parent
MouseArea{
anchors.fill: parent
propagateComposedEvents: true
onPressed: {
console.log("R2 pressed")
}
onReleased: {
console.log("R2 released")
}
}
}
}
What I expect to see :
qml: R1 pressed
qml: R2 pressed
qml: R1 released
qml: R2 released
What I get :
qml: R1 pressed
qml: R2 pressed
qml: R2 released
How can I solve that ?
Thanks in advance for your help .
Using propagateComposedEvents will not work because its behavior is only defined for composed events, which means one of clicked, doubleClicked and pressAndHold. So when you set mouse.accepted = false in R1's onPressed handler, this has nothing to do with propagateComposedEvents.
Setting mouse.accepted = false instead does what it is supposed to do according to the documentation:
no further events will be sent to this MouseArea until the button is
next pressed.
In my opinion, one should only react to mouse inputs on the topmost MouseArea. As long as R1 and R2 completely overlap with each other, you are making R2 something that it simply isn't. In case R1 is smaller than R2 and you want to do something for R2 in R1's handlers, just move the R2 code to a function and call it from both MouseAreas' event handlers. Or just use bindings to both Mouseareas' pressed state.
Related
I'm trying to create an animation in my app when a particular action happens which will essentially make the background of a given element change colour and back x number of times to create a kind of 'pulse' effect. The application itself is quite large, but I've managed to re-create the issue in a very basic app.
So the ContentView is as follows:
struct ContentView: View {
struct Constants {
static let animationDuration = 1.0
static let backgroundAlpha: CGFloat = 0.6
}
#State var isAnimating = false
#ObservedObject var viewModel = ContentViewViewModel()
private let animation = Animation.easeInOut(duration: Constants.animationDuration).repeatCount(6, autoreverses: false)
var body: some View {
VStack {
Text("Hello, world!")
.padding()
Button(action: {
animate()
}) {
Text("Button")
.foregroundColor(Color.white)
}
}
.background(isAnimating ? Color.red : Color.blue)
.onReceive(viewModel.$shouldAnimate, perform: { _ in
if viewModel.shouldAnimate {
withAnimation(self.animation, {
self.isAnimating.toggle()
})
}
})
}
func animate() {
self.viewModel.isNew = true
}
}
And then my viewModel is:
import Combine
import SwiftUI
class ContentViewViewModel: ObservableObject {
#Published var shouldAnimate = false
#Published var isNew = false
var cancellables = Set<AnyCancellable>()
init() {
$isNew
.sink { result in
if result {
self.shouldAnimate = true
}
}
.store(in: &cancellables)
}
}
So the logic I am following is that when the button is tapped, we set 'isNew' to true. This in turn is a publisher which, when set to true, sets 'shouldAnimate' to true. In the ContentView, when shouldAnimate is received and is true, we toggle the background colour of the VStack x number of times.
The reason I am using this 'shouldAnimate' published property is because in the actual app, there are several different actions which may need to trigger the animation, and so it feels simpler to have this tied to one variable which we can listen for in the ContentView.
So in the code above, we should be toggling the isAnimating bool 6 times. So, we start with false then toggle as follows:
1: true, 2: false, 3: true, 4: false, 5: true, 6: false
So I would expect to end up on false and therefore have the background white. However, this is what I am getting:
I tried changing the repeatCount (in case I was misunderstanding how the count works):
private let animation = Animation.easeInOut(duration: Constants.animationDuration).repeatCount(7, autoreverses: false)
And I get the following:
No matter the count, I always end on true.
Update:
I have now managed to get the effect I am looking for by using the following loop:
for i in 0...5 {
DispatchQueue.main.asyncAfter(deadline: .now() + Double(i), execute: {
withAnimation(self.animation, {
self.isAnimating.toggle()
})
})
}
Not sure this is the best way to go though....
To understand what is going on, it would help to understand CALayer property animations.
When you define an animation the system captures the state of a Layer and watches for changes in the animatable properties of that layer. It records property changes for playback during the animation. To present the animation, it create a copy of the layer in its initial state (the presentationLayer). It then substitutes the copy in place of the actual layers on screen and runs the animation by manipulating the animatable properties of the presentation layer.
I this case, when you begin the animation, the system watches what happens to the CALayer that backs your view and captures the changes to any animatable properties (in this case the background color). It then creates a presentationLayer and replays those property changes repeatedly. It's not running your code repeatedly - it's changing the properties of the presentation Layer.
In other words the animation the system knows the layer's background color property should toggle back and forth because of the example you set in your animation block, but the animation toggles the background color back and forth without running your code again.
QT5.5, QML:
I am using the example "Qt Quick Examples - Drag and Drop"
In this example, you could see that if we drag the red tile "1", it appears under other tiles when we drag it.
I don't like this effect since when we drag one item, I hope it always appears on the top of whole GUI.
What I tried is:
Once the mouse is pressed, we set the item's z as the largest value. And when the mouse is released, set the z to the small value (or better we could save the original value and reset it back to its original valule)
MouseArea {
id: mouseArea
width: 64; height: 64
anchors.centerIn: parent
drag.target: tile
onPressed: {
tile.z = 100;
}
onReleased: {
tile.z = 0;
parent = tile.Drag.target !== null ? tile.Drag.target : root
}
}
But the code does not work.
Actually by using console.log, I could see the z value changes, but the dragging ghost image still appears at the bottom.
So I guess when onPressed is implemented, the drag mechanism has used its original z value and gets no chance to access the updated z value.
So any idea to have a more decent drag movement?
Thanks!
The z value of items only applies to siblings and the immediate (direct) parent:
Items with a higher stacking value are drawn on top of siblings with a lower stacking order. Items with the same stacking value are drawn bottom up in the order they appear. Items with a negative stacking value are drawn under their parent's content.
Let's use a small example to test the parent/child scenario:
import QtQuick 2.3
import QtQuick.Window 2.0
Window {
visible: true
width: 200
height: 200
title: qsTr("Hello World")
flags: Qt.FramelessWindowHint
Rectangle {
color: "salmon"
width: 64
height: 64
anchors.centerIn: parent
Text {
text: "1"
}
Rectangle {
color: "steelblue"
x: 32
y: 32
width: 64
height: 64
Text {
text: "2"
}
Rectangle {
color: "orchid"
x: 16
y: -16
width: 64
height: 64
z: -2
Text {
text: "3"
}
}
}
}
}
We set the z value of the third Rectangle to -2, hoping that it would go behind the first one, but since it's a child of the second and not the first, it's out of reach. This is what's happening in the drag and drop example: the items are too far apart in terms of ancestory.
To elaborate further on this, let's take DragTile.qml from the Drag and Drop example and modify it in a similar way to yours (this is a nicer way of achieving the same thing, by the way):
states: State {
when: mouseArea.drag.active
ParentChange { target: tile; parent: root }
AnchorChanges { target: tile; anchors.verticalCenter: undefined; anchors.horizontalCenter: undefined }
PropertyChanges {
target: tile
z: 100
}
}
This also won't work. To see what's going on, we can use an awesome little environment variable called QSG_VISUALIZE. Specifically, we want to use the overdraw visualisation, which gives us a nice rotating 3D box containing our scene. Even with our PropertyChanges above, you can see that the stacking order of the item is unchanged:
To ensure that the item is rendered on top of everything, you need to parent it to an item that is actually above everything. We can do this by adding an Item to the end of tiles.qml:
Item {
id: dragContainer
anchors.fill: parent
}
Add a property to the DragTile component that gives the delegate access to the container:
property Item dragParent
Then, assign the container in tiles.qml:
delegate: DragTile { colorKey: "red"; dragParent: dragContainer }
Next, modify the parent property of the ParentChange in DragTile.qml:
ParentChange { target: tile; parent: dragParent }
The end result:
Note that I intentionally excluded the "back" button, but if you wanted to make it go above that as well for some reason, you can just move dragContainer higher up the hierarchy.
I am trying to add swipe and press support to an img using Hammer js version 2.0.4 and I have noticed that it does not work well on Desktop IE11. The gestures are triggered maybe once for every 20 attempts.
Here is a jsfiddle with an example.
http://jsfiddle.net/bhptL6mf/32/
$(function() {
var myImg = document.getElementById("myImg");
var blue = document.getElementById("blue");
var hammerManager = new Hammer.Manager(myImg);
var panRecognizer = new Hammer.Pan({
threshold: 0,
pointers: 0
});
hammerManager.add(panRecognizer);
var swipeRecognizer = new Hammer.Swipe({
threshold: 0,
velocity: 0.01
});
hammerManager.add(swipeRecognizer).recognizeWith(hammerManager.get('pan'));
hammerManager.on('swipe', function(event) {
if (event.type == 'swipe') {
($(blue).text() === "Swiped") ? $(blue).text(" "): $(blue).text("Swiped");
}
});
})
Anyone else seeing this issue and know of a workaround? I am also seeing the same issue when gestures are applied to anchors
Setting img attribute draggable to false will fix this on IE.
Also noticed a similar issue on Desktop Fire Fox and had to set -moz-user-select to none and prevent dragstart event in addition to setting draggable to false to fix it.
I have to create an mobile flex application with tabbed navigator view. One of the view must satisfy this condition: when the view is selected, an image will appear for one second and then disappear for half a second, then reappear at a random position on the screen of the view. This will repeat until another view is selected.
I'm new to Mobile Flex and I need your help.
Thanks you in advance.
Best regards,
HBLE
Use enterFrame event or a Timer to hide/show the image.
Set the image x and y properties to show the image at a specific position
Use Math.random() to generate a random number in the interval [0,1]
Important:
When tab is active call init();
When changing to other tab do not forget to stop the timer and remove event listeners.
(for performance reasons and to avoid memory leaks)
Sample code:
var isVisible:Boolean = false;
function init():void
{
// we show / hide with a delay of 1 second
var t:timer = new Timer(1000);
t.addEventListener(TimerEvent.Timer, onTimer);
t.start();
}
function onTimer(event:TimerEvent):void
{
if(isVisible)
{
hideImage();
}
else
{
showAndMoveImage();
}
isVisible = !isVisible;
}
function hideImage():void
{
myImage.visible = false;
}
function showAndMoveImage():void
{
// we reposition image in screen, assume image size is smaller then screen
myImage.x = Math.random() * (stage.width - myImage.width);
myImage.y = Math.random() * (stage.height - myImage.height);
myImage.visible = true;
}
I'm working on a site that makes use of v7 of the Bing Maps AJAX Control. One of the things I need to do is restrict the zoom level so as to prevent users from zoom in past a certain level, or zoom out past a certain level.
I found a "getZoomRange" method on the Map object, after inspecting it, it simply returns an object literal with "min" and "max" properties. So, I figured overloading it would probably do the trick:
// "map" is our Bing Maps object
map.getZoomRange = function ()
{
return {
max: 14
min: 5
};
};
...but no. It has no effect (it actually has something to do with the appearance of the zoom slider when using the default Dashboard).
Hijacking the event and preventing it from proceeding also seems to have no effect.
According to Bing Maps support, the only way to do this (which isn't particularly elegant, and results in some unwelcome jitter on the map) is as follows:
// "map" is our Bing Maps object, overload the built-in getZoomRange function
// to set our own min/max zoom
map.getZoomRange = function ()
{
return {
max: 14,
min: 5
};
};
// Attach a handler to the event that gets fired whenever the map's view is about to change
Microsoft.Maps.Events.addHandler(map,'viewchangestart',restrictZoom);
// Forcibly set the zoom to our min/max whenever the view starts to change beyond them
var restrictZoom = function ()
{
if (map.getZoom() <= map.getZoomRange().min)
{
map.setView({
'zoom': map.getZoomRange().min,
'animate': false
});
}
else if (map.getZoom() >= map.getZoomRange().max)
{
map.setView({
'zoom': map.getZoomRange().max,
'animate': false
});
}
};
I was dealing with a similar issue and I ended up doing something very similar to what MrJamin describes in his answer, with one (subtle, but major) difference: I added a handler for targetviewchanged. According to the official docs on MSDN, 'targetviewchanged' occurs when the view towards which the map is navigating changes. Also, instead of calling Map#getZoom, I used Map#getTargetZoom which returns the zoom level of the view to which the map is navigating. Note, this approach prevents jitter.
Here's the shortened version of my code:
function restrictZoom(map,min,max) {
Microsoft.Maps.Events.addHandler(map,'targetviewchanged',function(){
var targetZoom = map.getTargetZoom();
var adjZoom = targetZoom;
if(targetZoom > max) {
adjZoom = max;
} else if(targetZoom < min) {
adjZoom = min;
}
if(targetZoom != adjZoom) {
map.setView({zoom:adjZoom});
}
});
}
Another way to achieve this is to handle the event thrown when the mouse wheel is moved. http://msdn.microsoft.com/en-us/library/gg427609.aspx
When you handle the mousewheel event, you can check whether the mouse wheel is being scrolled forwards or backwards, and then check the map.targetZoom() in order to compare with a min or max zoom value. If the min or max are exceeded, then set event.handled = true. This prevents the event from being handled by any other handlers which prevents default behaviour. From the documentation:
A boolean indicating whether the event is handled. If this property is
set to true, the default map control behavior for the event is
cancelled.
See below:
var Zoom = {
MAX: 10,
MIN: 2
}
var mouseWheelHandler = function(event) {
// If wheelDelta is greater than 0, then the wheel is being scrolled forward which zooms in
if(event.wheelDelta > 0) {
if(map.getTargetZoom() >= Zoom.MAX) {
event.handled = true;
}
}
else {
if(map.getTargetZoom() <= Zoom.MIN) {
event.handled = true;
}
}
}
Microsoft.Maps.Events.addHandler(map, 'mousewheel', mouseWheelHandler);