开发者

Resize AIR app window while dragging

开发者 https://www.devze.com 2022-12-25 06:20 出处:网络
So I\'ve noticed Windows 7 has a disturbing tendency to prevent you from dragging the title bar of windows off the top of the screen. If you try - in this case, using an air app with a draggable area

So I've noticed Windows 7 has a disturbing tendency to prevent you from dragging the title bar of windows off the top of the screen. If you try - in this case, using an air app with a draggable area at the bottom of the window, allowing you to push the top of the window up past the screen - it just kicks the window back down far enough that the title bar is at the top of what it considers the 'visible area.'

One solution would be to resize the app window as it moves, so that the title bar is always where windows wants it. How would you resize the window while you're dragging it, though? Would you do it like this?

dragHitArea.addEventListener(MouseEvent.MOUSE_DOWN, function(e:MouseEvent):void{
    stage.nativeWindow.height += 50;
    stage.nativeWindow.startMove();
    stage.nativeWindow.height -= 50;
});

see what's going on there? When I click, I'm doing startMove(), which is hooking into the OS' function for dragging a window around. I'm also increasing开发者_JAVA技巧 and decreasing the height of the window by 50 pixels - which should give me no net increase, right?

Wrong - the first '.height +=' gets executed, but the '.height -=' after the .startMove() never runs.

Why?


have you tried looking into the NativeWindowBoundsEvent.MOVING event?

stage.nativeWindow.addEventListener(NativeWindowBoundsEvent.MOVING, windowMove);
private function windowMove(e:NativeWindowBoundsEvent) : void {
    trace(e.beforeBounds);
    trace(e.afterBounds);
    // resize window as needed based on these
}

references: Google, which led me to http://lowpitch.com/blog/nativewindow-using-air-windows-with-actionscript-part-3-of-3/ which led me to http://livedocs.adobe.com/flex/3/langref/flash/events/NativeWindowBoundsEvent.html

NativeWindowBoundsEvent.MOVING is fired before the position actually changes, whereas NativeWindowBoundsEvent.MOVE is fired after the position has changed, if you were wondering. Thus you would need the MOVING event

(by the way, I was tempted to just say "you can't" without doing any research for the bounty... but felt that would be mean)


I have developed a similar app, with fly-out windows, and after encountering some problems I've decided to get rid of the NativeWindows, and do everything in one chromeless window the size of the screen. I was resizing the window to the size of the screen every time the app was starting. I have designed a custom title bar with buttons and everything, and the main window of the widget was actually a Canvas, which I dragged around on the app's window. Same thing with the fly-out menus and windows: they were just components based on Canvas. I had no problems dragging a component outside the visible area of the window, because it was the same as the screen.

But, like I said, it may be late to make such a drastic change.


This seems like it would be a funny effect and not all standard window behavior. Why do you feel the need to do anything? Why not let the user resize the window themselves if they need to?

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号