using a timer works just fine. and i don’t believe any “debouncing” is
necessary as the timer can’t fire if i am already in the process of resizing.
thanx ken and quincey,
ken
On Jun 23, 2011, at 3:57 PM, Ken Victor wrote:
> empirically, it appears that the event tracking loop for window resiz
empirically, it appears that the event tracking loop for window resizing is
calling
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
so i can’t simply override NSWindow’s matching method in my subclass. thus,
while overriding NSApplication’s method is probably doable, i b
On Jun 23, 2011, at 14:55, Ken Victor wrote:
> lets say the user had been resizing the window without any modifier keys
> pressed, but then realized what s/he really wanted was to resize in only one
> dimension or to maintain the window’s aspect ratio, so now s/he presses
> either shift or shif
On Jun 23, 2011, at 2:40 PM, Ken Thomases wrote:
> Hi Ken,
>
> On Jun 23, 2011, at 4:12 PM, Ken Victor wrote:
>
>> so… anyone have any other ideas as to how to get called for a modifier key
>> change will in the midst of a live resize?
>
> I'm a bit confused as to why this would be helpful?
Hi Ken,
On Jun 23, 2011, at 4:12 PM, Ken Victor wrote:
> so… anyone have any other ideas as to how to get called for a modifier key
> change will in the midst of a live resize?
I'm a bit confused as to why this would be helpful? Why is
-windowWillResize:toSize: too late for your needs? Your
i’ve got a subclass of NSWindow (MagneticWindow) that provides:
- (NSSize) windowWillResize: (NSWindow*) sender toSize: (NSSize)
frameSize;
i use this to provide constrained live resizing of the window, i.e., if the
shift key is down, the window will only resize in the horizontal or verti
