I am developing an application in Adobe Air exe using two monitors, the application calculates how many monitors have the computer, and calculates using a rectangle to populate them.
So far so good, my question is why the mouse cursor has the decision to be the primary monitor.
For example: If I open the application on the left screen, the application starts on the left screen, open the application on the right screen, the application opens on the right screen.
Is there any way to prevent the mouse to make the management of the main monitor?
I would use the Screen Class.
var screenList:Array = Screen.screens;
stage.nativeWindow.x = screenList[0].visibleBounds.left;
stage.nativeWindow.y = screenList[0].visibleBounds.top;
Related
I have written a Win32 C++ program.
I would like to duplicate the visual content of the left window every frame, so it appears at another location on the screen. (One rectangle on the left side of the screen, and an identical rectangle on the right side of the screen.)
This is for stereo rendering, where the left rectangle is seen in the user's left eye, and the right rectangle in the right eye.
The two rectangles must be "frame synced", meaning that they must show the same frame at all times. Or to put it another way, if the right eye is behind the left by "one draw call", then the viewer becomes ill.
NOTE: I have the source code to both windows, because I created them. (Both windows reside within the same exe at the moment.)
What I have tried:
BitBlt(), by drawing a rectangular portion of the desktop HDC into the right-side window. I am calling BitBlt() in the WM_PAINT message of the right-side window: This works, BUT the right-side window is 1-2 frames behind the left.
Potential Solutions:
In the left-window's WM_PAINT message, draw both windows with the same contents. Is this possible somehow?
Use one, single giant window to draw both rectangles. This would mean all drawing occurs in the same WM_PAINT call. However, I do not know how to copy part of a window to another part. I wish I could just tell Win32 to 'draw again', but this time start 1000 pixels to the right...
Do "something" with DirectX. (No idea what.)
Any help would be greatly appreciated!
I don’t know if you still need an answer, but I don’t think you can do it better than using the DWM Thumbnails API [1]. You basically do an association of a region on your window <-> a region of a foreign window, and then each time the windows are composed and presented on the screen, the specified rectangle of the foreign window will be painted on the specified rectangle of your window. DWM will do scaling if necessary and you can also specify a transparency level. This is the most efficient way to do it, as the compositor does all the heavy lifting, so it is at the lowest level you could go without writing kernel mode code (custom drivers etc). You can’t draw on top, and won’t “see” the foreign window data on your window if you BitBlt it for example, as the image is not actually drawn on your window, but overlaid on top when the final image of your window is composed and presented to the user by the window manager. But for most purposes, it works really well.
[1] https://learn.microsoft.com/en-us/windows/win32/dwm/thumbnail-ovw
Using Surface pro touch screen to select element in viewer works sometimes other times it seems to translate to a rotate/zoom action. In this case the viewer rotates/moves and the element is NOT selected.
When logging the events there are plenty of mouse down/up events along with mouse moves when it doesnt work. When select does work a single click event occurs.
Double click seems to work ok.
Zoom/rotate etc using standard tools works ok.
Using the keyboard cover touch pad that you can get for the Surface pro to move and click works as expected and the element is selected.
Running same application on a GETAC Windows 10 ruggadised tablet the select element works correctly so it seems related to the Surface Pro.
Unable to change browsers as cordova apps use IE11 on windows and that is currently fixed.
The only solution i can think of for the moment is to remove the standard navigation tools completely (somehow) and recreate a select mode tool that would ignore any mouse moves and use button down event to select element.
Any suggestions on how to fix this?
Tech Details:
Windows 10 Pro,
Surface Pro,
Browser: IE11,
Viewer version 2.11,
Other: WINJS81 cordova application
Thanks for any help
We've had problems with touch events on the Surface Pro in the past. It sounds like the edges of the touch screen are overly sensitive and are triggering extra touch points.
Does the problem happen if you are holding the device up, gripping with one hand, and using your other hand to touch/select a 3D object ?
Could you try doing a selection again, but this time, make sure you other hand is not holding the edge of the screen? (Perhaps place the device on the surface of a desk, so you are not holding it up)
Found a fix to this issue. In viewer3D in the base toolcontroller there is line
var kClickThreshold = 2;
This value is used further down in code to determine if singleClick has occured. It does it by comparing XY on down and up events.
var deltaX = _downX - event.canvasX;
var deltaY = _downY - event.canvasY;
_downX = -1;
_downY = -1;
if( Math.abs(deltaX) <= kClickThreshold && Math.abs(deltaY) <= kClickThreshold )
_this.handleSingleClick( event );
If movement is above this threshold it does not trigger singleClick if below it does.
Did testing and increasing the value to around 5-7 means that the selection of elements worked consistently. (there is still a minor rotate or zoom at same time as select occurs but I assume that this would be another part of viewer that would need adjusting)
Unfortunately it does require edit of viewer code but easy enough. I added code to overwrite standard value if external variable existed.
Would be nice for future viewer dev if more of these types of properties be exposed so that direct edit of code is not required.
Still it is good to have the source code to be able to debug at this level.
At a guess the Surface Pro 4 must have a more sensitive touch system or it could just be related to IE11 as well.
In my Adobe Air application, I have a room and my player that can walk around it. I set it so it automatically opens in fullscreen, however, when you exit fullscreen it doesn't scale anything, so it just shows you the edge of the room, where you can't see the player or anything else. How do I make it so that when you exit fullscreen, everything will scale down to the windowed version, and back again? This is in Adobe Flash Builder 4.7.
I tried scaling everything down by putting an If statement in an update function, that constantly checks if the window is full screened or not, and if not, it'll scale the x and y down by .5, and if full screened again, it'll scale it back up by 1. The player however changes position, and if I try to make the X equal it it just does it again if I move the player, so it doesn't work. I've also tried verticleCenter and horizontalCenter on both the player and room, it also doesn't work.
What I'm wondering is if there is a stage.autoScale line that can solve everything, or if I have to do it manually another way like I've tried.
So you got 2 options here.
Check for fullscreen event and then in the listener function scale everything according to your logics. This will give you more control over the scaling and visual display of your components and graphics. You can find a working example for fullscreen event handling at http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS2E9C7F3B-6A7C-4c5d-8ADD-5B23446FBEEB.html
Allow FP to scale the stage according to the window size. This can be achieved by setting up stage.scale mode. There are couple options which you can find at http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/StageScaleMode.html. Use the one best suit for your application.
I would prefer using first method. Hope that make sense.
I've created an AIR application and it seems to be working fine but when I drag the title bar to move the native window it shakes violently and have seizures while it's dragging about.
FYI It does eventually end up where I want it to be when I stop moving the mouse.
I'm using Flex 4.6 and AIR 3.6 on Mac OSX 10.10.5. It's a s:WindowedApplication I'm also using the DragManager on a list in part of the application if that matters but it is not enabled until the user clicks into the list and moves more than a certain number of pixels.
Here is my descriptor file minus name and version info:
<application xmlns="http://ns.adobe.com/air/application/3.6">
<initialWindow>
<autoOrients>false</autoOrients>
<fullScreen>false</fullScreen>
<visible>false</visible>
</initialWindow>
</application>
On initialize I run this:
protected function initializeHandler(event:FlexEvent):void {
width = Capabilities.screenResolutionX * .96;
height = Capabilities.screenResolutionY * .9;
nativeWindow.x = (Screen.mainScreen.bounds.width - width)/2;
nativeWindow.y = (Screen.mainScreen.bounds.height - height)/2;
}
UPDATE:
I removed the main view component so it is an empty application and it drags around smoothly.
UPDATE 2:
I added the main view back in and dragged around step by step along the way. It appears to start happening when I've loaded a second Application (called a sub application) into the main application. I'm not sure though.
This happens in numerous number of my applications. It is probably because I have a component inside my application file set to size to 100% of the application. But I have not verified this on all my apps.
The solution is to resize the AIR app. After I resize it it works fine. I can drag it around and it works as expected. I think this is an AIR bug.
For example, how would I draw an image outside of my window area, anywhere on the screen?
It is not possible to draw outside your window. You can however simulate that effect by creating a maximized transparent window and then drawing on it so that it seems you are drawing at arbitrary points on the screen. You will face issues like the visible windows below the transparent window will be inactive till you minimize the transparent window.
You can also create a new window inside your application and place it somewhere on the screen. If you set systemChrome to none it will not have any menu bars and will appear if there is nothing on the screen unless you fill it.
See http://livedocs.adobe.com/flex/3/html/help.html?content=WorkingWithWindows_1.html for more information about windows.
A tutorial to spawn new windows without any menu bars and outlining is here : http://www.adobe.com/devnet/air/flex/quickstart/articles/creating_toast-style_windows.html