I have items that can be dropped only to a small DropArea (called AcceptDropZone). This works fine.
Now I want the following behavior : if items are dropped elsewhere, they go back to their starting position when the user releases the mouse. To do this, I have added another DropArea (called RejectDropZone) in the background, that fills the entire window of the application.
The problem is that RejectDropZone consumes the onDropped event even when the items are dropped over AcceptDropZone. As RejectDropZone is in the background of the QML stack, I was expecting AcceptDropZone to get the event first, as for MouseArea components.
Is this a bug or a valid behaviour of overlapping DropAreas? How can I get the result I am looking for?
Thanks for your help;
Regards
For those who may be interested, here is the solution to my problem:
https://forum.qt.io/topic/71036/droparea-overlapping/6
Regards
Related
I have a toolbar defined as "toolBar" property of a ApplicationWindow.
When I resize the window I want that toolBar (if it's too large for the current size) handle overflow with a "more" item. After a lot of research I couldn't found anything on the web. I join some screenshot of what I have and what I want.
The second example is something I have done in pure C++.
In my research I also read something about toolbar only handle overflow in MainWindow and that maybe why I can't make it work in ApplicationWindow.
Thanks for your help.
It could be done if you go for a model driven toolbar items.
Then, if the toolbar view is not wide enough to fit everything, you can calculate the index it cuts out at, and implement a drop down menu with another view, this time vertical, that shows only items after the cutout index.
It is not ideal, but since there is no built in support for that, this is by far the easiest and quickest way to get the desired result.
This question is regarding QML, QtQuick 1.1, Qt 4.8.6
I have seen source code of an embedded application, in which all the screens are loaded at start. For Example,
//Main.qml
Rectangle{ //Base Container
width:640
height:480
MainScreen{ id: main_screen} //Individual screen files are given here
SettingScreen1 { id:screen1}
SettingScreen2 { id:screen2}
HelpScreen1 {id: help_screen1}
...
...
...
}
and in the respective screen document, when a mouse area is clicked the Value of Z of the individual document is changed to make it appear front
//MainScreen.qml
Rectangle{
width: 640
height:480
z:1
//some buttons
//Mousearea for next button
onClicked: {screen1.z = 10}
//Mousearea for back button
onClicked: {screen1.z = 0}
}
My question is,
1. As from main.qml all the children are created at once and only their visibility of stack order is changed. Is this a good method?
2. When so many children are loaded at beginning what happens if I have like 200 screens. What is the effect in CPU load at start and while operation.
Is there any other method for screen transitions?
Other than component loader. I don`t want to use that feature
How this code is converted and showed in display as an object?
I will be very happy is least you can give hints in comments.
Thanks!!
To your questions:
1): Bad Idea. Using the z-index needs the engine to determine that the lower items are hidden completely. You should help the enigne if you are sure about this (which would be the case here) by setting the visibility to false. Then however, you would not need to use the z-index at all. Don't use the z-index. Don't!
However this won't solve that you might have 200 possibly complex views in your memory.
The Loader you mentioned is already a better start.
You can use it in combination with the visibility to preload pages that are likely to be shown soon, and unload them once you are sure they are not shown anytime soon (within the next one or two clicks)
2): The effect is: Long time of unresponsivenes until everything is loaded. The documentation sais: Show a splash-screen if you want to do something like this. In order to show the splash-screen, show it, then use a Loader to load all the other stuff... But in general: Don't do it, if not absolutly necessary. Load dynamically. Never use the z-index to hide screens completely. Load only what needs to be loaded... I feel repetitive...
I have a scrollable and flickable ListView with 5+ elements and I'd like to have the elements which are shown at both ends zoomed out, transparent and slightly moved so the whole list becomes rounded up, sort of getting the shape of a wheel.
I think the two images describe it best:
That's what I have:
And that's what I want:
Since I'm also targeting devices without GL - although deprecated - I'd prefer a QtQuick 1.x version, however I'm happy with all I can get :)
Thanks a lot in advance!
The ListView is not exactly meant to do that.
Have a look at the PathView.
There are a lot of examples from the documentation, maybe you'll find there something very similar to what you want to do.
Otherwise you should put a MouseArea in your delegate and react to the entered and exited signals. Do not forget to update the size of the delegate accordingly to the size of its content if needed, otherwise the items will overlap each other.
That said, I'd maybe use the PathView to do that.
I have a problem with redrawing in flex 4. I have a spark titleWindow, and if i drag it faster, it looks like it's mask is one frame late after the component.
it's easily visible with 1pixel thin border, because it becomes invisible even with slower movement.
You can try it here (what is not my page, but it's easier to show you here than uploading example):
http://flexponential.com/2010/01/10/resizable-titlewindow-in-flex-4/
If you move in direction up, you see disappearing top border. in another directions it's not that sensitive as it has wide shadow, and it's not very visible on shadow.
On my computer i see it on every spark TitleWindow i have found on google, although it's much less visible with less contrast skins, without borders or with shadows.
Do you see it there? i had never this problem with halo components. It's doing the same thing with different skins. I tried to delete masks from skin, cache component, skin even an application as bitmap with no success.
I also turned on redraw regions in flash player, and it looks like it's one frame late after titlewindow too.
Does anyone know why is it doing this or how can i prevent it?
Thank you
UPDATE:
no answers? really?
I have been facing the same problem and I was really pissed that I couldn't find any answer.
The problem with me was, that I tried to center the component "component.x = (parent.width - component.width) / 2" and then draw that component programatically. The problem was, that component.x is a Number which can lead to floating values like 10.5 or similar. And it looks like that bitmapFill function rounds floats DIFFERENTLY than drawRect function, which makes exactly the 1px line around the objects (but ONLY when parent.width is an odd number). Strange thing for me was, that I only called the Draw function once, but still this line keep recurring ...
Doing Math.floor(component.x) solved the issue.
P.S.: I think that you can also help your issue by setting cacheAsbitmap=true on the dragged object ...
Cheers,
Jan Prazma
I'm developing a Flex 2 application, and I noticed that part of the library which is responsible for moving GUI windows (TitleWindows) around when you drag them with the mouse gets confused if there is a clickable (buttonMode = true) sprite beneath them. When I say confused, I mean that the window is moved around normally for a while, but then at some point "jumps" into the upper left corner of the flash app, and makes very minor movement there. Then at some other point it jumps back. It is more difficult to explain than to experience, so please go and see for yourself. Here's how to reproduce the problem:
Go to http://www.panocast.com
In the left sidebar, choose "Real Estate"
Just below the bottom right corner of the flash window, choose "high res" by clicking on the rightmost icon.
When (part of) the video loads, click on the staircase. A TitleWindow will pop up.
Try dragging it around the screen. When the mouse cursor is moved above one of the clickable areas (like the staircase), the window is misplaced.
(Sorry, but can't give you a direct link, part of the page is generated dynamically.)
(What's makes the problem even more interesting is that for me, in "low res" mode, the problem does not occur! There is very little difference between the various modes.) I would really appreciate if someone told me what was going on here and how it can be fixed.
I'm not sure if it matters, but the underlying sprite is actually not just plain sprite, rather it is a Papervision3D renderer object with some 3D elements in it. I'm telling this because it is possible that the incorrect mouse coordinates somehow come from the texture UV mapped on the clickable objects.
I've managed to replicate this on the low res mode as well, so I don't think it's related to the resolution.
This looks to be because the MouseEvent is being handled by the TitleWindow AND the Papervision3D window. Perhaps you need to force stopImmediatePropagation() on one or the other? Or maybe switch off the MouseEvent handling for the Pv3D window when the TitleWindow pops up?
That's a tough one to debug without some source; something's apparently calling either move() or setting x and y properties on that TitleWindow and scheduling it be moved.
When I first read the post, it "smelled" like maybe a rotation miscalculation somewhere (using Math.atan vs. Math.atan2 can sometimes have that kind of effect), so you're right, it could have something to do with PaperVision, assuming you're not using Math.atan or setting rotation properties yourself anywhere. Just thought I'd mention it, though it's probably not happening in your case. You never know, though. ;)
More likely the LayoutManager is moving the component in response to a property change on the component. The Flex docs explain that in addition to setting its x and y properties, and explicit calls to move(), a UIComponent's move event can also be triggered when any of the following other properties change:
minWidth
minHeight
maxWidth
maxHeight
explicitWidth
explicitHeight
PaperVision or no, maybe that info might help you isolate the source of the move. Good luck.
I got this figured out. Apparently, this is a Papervision3D problem. There is a class deep inside Papervision3D called VirtualMouse, which is supposed to generate MouseEvents programmatically. This happens, for example, when the user interacts with any of the interactive objects on stage, e.g., a Plane with an interactive material on it (as in my case).
The problem is that the x and y coordinates of the generated event represent texture UV coordinates (just as I suspected) and not real world screen coordinates. When a TitleWindow (or any Panel object) is dragged, a "mouseMove" handler (among others) is added to the SystemManager, which then uses the stageX and stageY properties of the event object to determine the new position of the window. Unfortunately for VirtualMouse's mouse events, these are invalid, since the original x,y coordinates, which are probably used to determine the global stage coordinates are, as I said, not screen coordinates.
Honestly, I'm still unsure whether the events dispatched by VirtualMouse are used anywhere within Papervision3D itself, or they are just offered for convenience, but they sure make it difficult to integrate a viewport into a Flex program. Assuming that such events aren't necessary for PV3D itself, there is a one-liner fix for my problem, which must be added right after the creation of the viewport:
viewport.interactiveSceneManager.virtualMouse.
disableEvent(MouseEvent.MOUSE_MOVE);
BTW., there was a very similar (or rather, as it turns out, the same) bug with dragging sliders, also fixed by this line.