Accessibility Settings

[Tom Doan via Cocoa-dev]

I'm trying to figure out how to query the value for the 
Accessibility---Display---Text Size for MacOS (Objective-C). I can't 
for the life of me find any documentation on it, and anything that 
looks even close appears to be for iOS and Swift. Can anyone point 
me in the right direction?

Best regards,

Tom Doan
---
Estima
2717 Harrison St
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Intermittent invisible NSWindow

[Tom Doan via Cocoa-dev]

Unfortunately, it appears that it's 100% predictable---it fails on a M1 
chipped computer and works on an Intel chipped computer (or an 
M1 running the software through Rosetta).

> I can say it has been true in the past, even if it is no longer the
> case. It is not something I test with each OS release. I certainly can
> move a window almost entirely offscreen-enough to not notice it at
> least. Also, your suggestion that the window may have an invalid size
> could also be the case, additionally revealed by logging the window
> frame. I have seen some auto layout wonkiness that forces  too-small
> frame, though not enough to  make it disappear. 
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 
> 
> 
> > On Nov 15, 2021, at 7:13 AM, Tom Doan via Cocoa-dev
> >  wrote:
> > 
> > Thanks, but is that true? I've tried forcing the window off screen
> > with setFrame: and it still shows up (generally pinned to the top of
> > the visible frame) even though the [NSWindow frame] returns the
> > "off-screen" location that I programmed in. The only way I have
> > found to make the window "invisible" is to give it a non-positive
> > size, and then pulling it off the window menu still won't show it.
> > 
> >> Have you logged the window coordinates? It might be placed fully
> >> offscreen, and that would produce the behavior you are seeing.
> >> 
> >> Keary Suska
> >> Esoteritech, Inc.
> >> "Demystifying technology for your home or business"
> >> 
> >> 
> >> 
> >>> On Nov 13, 2021, at 9:52 AM, Tom Doan via Cocoa-dev
> >>>  wrote:
> >>> 
> >>> I'm having a problem with an application where a small percentage
> >>> of users have one particular NSWindow type which doesn't show even
> >>> though it goes through a makeKeyAndOrderFront. It's on the window
> >>> list and will open if they do a tile, cascade or window switch
> >>> operation, but doesn't come up initially. I can't reproduce this
> >>> on any of my computers running three different flavors of MacOS
> >>> (including Big Sur and Monterey). What should I be looking for
> >>> that might cause this behavior.
> >>> 
> >>> Best regards,
> >>> 
> >>> Tom Doan
> >>> ---
> >>> 2717 Harrison St
> >>> Evanston, IL 60201
> >>> USA
> >>> 
> >>> 
> >>> ___
> >>> 
> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> >>> 
> >>> Please do not post admin requests or moderator comments to the
> >>> list. Contact the moderators at
> >>> cocoa-dev-admins(at)lists.apple.com
> >>> 
> >>> Help/Unsubscribe/Update your Subscription:
> >>> https://lists.apple.com/mailman/options/cocoa-dev/cocoa-dev%40esot
> >>> er itech.com
> >>> 
> >>> This email sent to cocoa-...@esoteritech.com
> >> 
> > 
> > 
> > ---
> > 2717 Harrison St
> > Evanston, IL 60201
> > USA
> > 
> > 
> > ___
> > 
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> > 
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> > 
> > Help/Unsubscribe/Update your Subscription:
> > https://lists.apple.com/mailman/options/cocoa-dev/cocoa-dev%40esoter
> > itech.com
> > 
> > This email sent to cocoa-...@esoteritech.com
> 


---
2717 Harrison St
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Intermittent invisible NSWindow

[Tom Doan via Cocoa-dev]

Thanks, but is that true? I've tried forcing the window off screen with 
setFrame: and it still shows up (generally pinned to the top of the 
visible frame) even though the [NSWindow frame] returns the 
"off-screen" location that I programmed in. The only way I have 
found to make the window "invisible" is to give it a non-positive size, 
and then pulling it off the window menu still won't show it.

> Have you logged the window coordinates? It might be placed fully
> offscreen, and that would produce the behavior you are seeing.
> 
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
> 
> 
> 
> > On Nov 13, 2021, at 9:52 AM, Tom Doan via Cocoa-dev
> >  wrote:
> > 
> > I'm having a problem with an application where a small percentage of
> > users have one particular NSWindow type which doesn't show even
> > though it goes through a makeKeyAndOrderFront. It's on the window
> > list and will open if they do a tile, cascade or window switch
> > operation, but doesn't come up initially. I can't reproduce this on
> > any of my computers running three different flavors of MacOS
> > (including Big Sur and Monterey). What should I be looking for that
> > might cause this behavior.
> > 
> > Best regards,
> > 
> > Tom Doan
> > ---
> > 2717 Harrison St
> > Evanston, IL 60201
> > USA
> > 
> > 
> > ___
> > 
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> > 
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> > 
> > Help/Unsubscribe/Update your Subscription:
> > https://lists.apple.com/mailman/options/cocoa-dev/cocoa-dev%40esoter
> > itech.com
> > 
> > This email sent to cocoa-...@esoteritech.com
> 


---
2717 Harrison St
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Intermittent invisible NSWindow

[Tom Doan via Cocoa-dev]

I'm having a problem with an application where a small percentage 
of users have one particular NSWindow type which doesn't show 
even though it goes through a makeKeyAndOrderFront. It's on the 
window list and will open if they do a tile, cascade or window switch 
operation, but doesn't come up initially. I can't reproduce this on any 
of my computers running three different flavors of MacOS (including 
Big Sur and Monterey). What should I be looking for that might 
cause this behavior.

Best regards,

Tom Doan
---
2717 Harrison St
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and C++ structures

[Tom Doan via Cocoa-dev]

Thanks. That did it. Interestingly, not only did the Applie Migration 
tool not flag a potential problem, but the docs on NSWindow and 
releaseWhenClosed don't even hint of it.


> Hi Tom,
> 
> > On Sep 14, 2021, at 9:53 AM, Tom Doan via Cocoa-dev
> >  wrote:
> > 
> > I have a multiple platform application (Windows, Mac, GTK) that is
> > primarily organized using C++ with Objective-C used for the
> > Mac-specific interface. I recently switched to use ARC (as we are
> > using Scintilla which recently switched to ARC). However, I am
> > getting a zombied release of an NSWindow instance. So far as I can
> > tell, the memory handling of this seemed to be fine pre-ARC.
> > Unfortunately, because it's an NSWindow, the Instruments output for
> > it has 100's of toolbox calls, so it's very hard to tell where the
> > extra release is. What should I be looking for? 
> > 
> > Just to describe this, there's an EWindow C++ structure which has
> > the NSWindow * as a member (under Mac OS; it's an HWND under Windows
> > and Widget under GTK). It's after the delete of the EWindow that
> > things go south. I'm assuming that ARC is putting in a release, but
> > I haven't really seen any good description of how ARC interacts with
> > C++. A release there seems fine---the question is where is the
> > earlier (apparently erroneous) release.
> 
> ARC will insert code at the end of your C++ destructor to release any
> strong id members.
> 
> One possible wrinkle is the default release-when-close behavior of
> NSWindow.  By default, when an NSWindow is `-close`d (which can only
> happen once in its lifetime), AppKit sends it a `-release`.  The idea
> is that this release balances the initial `+alloc`.
> 
> However, this is somewhat incompatible with ARC, which doesn´t know
> about this special behavior and will attempt to insert its own release
> to balance the alloc.
> 
> Here is an example of a program that works perfectly fine under MRR
> but crashes under ARC:
> 
> #import 
> 
> NSWindow *window;
> 
> int main(void) {
> @autoreleasepool {
> window = [[NSWindow alloc]
> initWithContentRect:NSMakeRect(0., 0., 100.,
> 100.) styleMask:NSWindowStyleMaskTitled
> backing:NSBackingStoreBuffered defer:NO];
> [window makeKeyAndOrderFront:nil]; [window
> close]; window = nil;
> }
> }
> 
> You can disable this behavior by changing the `releasedWhenClosed`
> property of the window to `NO`:
> 
> [window setReleasedWhenClosed:NO];
> 
> Matt
> 


---
2717 Harrison St
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

ARC and C++ structures

[Tom Doan via Cocoa-dev]

I have a multiple platform application (Windows, Mac, GTK) that is 
primarily organized using C++ with Objective-C used for the 
Mac-specific interface. I recently switched to use ARC (as we are 
using Scintilla which recently switched to ARC). However, I am 
getting a zombied release of an NSWindow instance. So far as I 
can tell, the memory handling of this seemed to be fine pre-ARC. 
Unfortunately, because it's an NSWindow, the Instruments output 
for it has 100's of toolbox calls, so it's very hard to tell where the 
extra release is. What should I be looking for? 

Just to describe this, there's an EWindow C++ structure which has 
the NSWindow * as a member (under Mac OS; it's an HWND under 
Windows and Widget under GTK). It's after the delete of the 
EWindow that things go south. I'm assuming that ARC is putting in a 
release, but I haven't really seen any good description of how ARC 
interacts with C++. A release there seems fine---the question is 
where is the earlier (apparently erroneous) release.

Tom Doan
Estima
---
2717 Harrison St
Evanston, IL 60201
USA

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSToolbar in Catalina

[Tom Doan via Cocoa-dev]

On looking at the particulars of the icons that are working and those 
that are not, it looks like anything that has a high resolution (128 x 
128) is displaying wrong, while the ones that I never updated from 
48 x 48 work correctly.

> I had a similar problem with .icns files showing weird graphics but on
> Mojave and earlier they were fine.  I resolved the issue by using Icon
> Composer (on macOS 10.10) to extract the '.icns' file(s) to iconsets
> and then importing them into an Asset Library.
> 
> The NSImage creation changed to use imageForResource
> 
> image = [NSBundle imageForResource:imgName];
> 
> -Dave
> 
> On 3/23/20, 1:10 PM, "Cocoa-dev on behalf of Tom Doan via
> Cocoa-dev"  on behalf of Cocoa-dev@lists.apple.com> wrote:
> 
> To provide a bit of additional information, the toolbar icons are
> fetched with
> 
> image  = [[NSImage alloc] 
> initByReferencingFile:[mainBundle 
> pathForResource:identifier ofType:@"icns"]];
> 
> 
> > I'm having a very odd problem. I use NSToolbar/NSToolbarItem to
> > manage toolbars in my application. Under Catalina (and
> apparently only > under Catalina), some of our users (only a few,
> and not me on my > development machines) end up with toolbar items
> that have a very odd > appearance---some are fine, some are
> completely whited out, some are > almost completely whited out
> with some odd colors added, usually pale > pink in an area which
> has nothing to do with the original icon > appearance. The washed
> out icons have nothing to do with them being > tagged
> inactive---on my machine, inactive icons look correctly dimmed >
>     and the washed out ones are supposed to be active anyway. Does
> anyone > have an idea what the problem might be? > > Best regards,
> > > Tom Doan > Estima > --- > 2717 Harrison St > Evanston, IL
> 60201 > USA > > > ___
> > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please
> do not post admin requests or moderator comments to the list. >
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com > >
> Help/Unsubscribe/Update your Subscription: >
> https://lists.apple.com/mailman/options/cocoa-dev/tomd%40estima.co
> m > > This email sent to t...@estima.com
> 
> 
> ---
> 2717 Harrison St
> Evanston, IL 60201
> USA
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the
> list. Contact the moderators at
> cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/david.stjohn%40x
> erox.com
> 
> This email sent to david.stj...@xerox.com
> 
> 


---
2717 Harrison St
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSToolbar in Catalina

[Tom Doan via Cocoa-dev]

To provide a bit of additional information, the toolbar icons are 
fetched with

image  = [[NSImage alloc] 
initByReferencingFile:[mainBundle 
pathForResource:identifier ofType:@"icns"]];


> I'm having a very odd problem. I use NSToolbar/NSToolbarItem to 
> manage toolbars in my application. Under Catalina (and apparently only
> under Catalina), some of our users (only a few, and not me on my
> development machines) end up with toolbar items that have a very odd
> appearance---some are fine, some are completely whited out, some are
> almost completely whited out with some odd colors added, usually pale
> pink in an area which has nothing to do with the original icon
> appearance. The washed out icons have nothing to do with them being
> tagged inactive---on my machine, inactive icons look correctly dimmed
> and the washed out ones are supposed to be active anyway. Does anyone
> have an idea what the problem might be?
> 
> Best regards,
> 
> Tom Doan
> Estima
> ---
> 2717 Harrison St
> Evanston, IL 60201
> USA
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/tomd%40estima.com
> 
> This email sent to t...@estima.com


---
2717 Harrison St
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSToolbar in Catalina

[Tom Doan via Cocoa-dev]

I'm having a very odd problem. I use NSToolbar/NSToolbarItem to 
manage toolbars in my application. Under Catalina (and apparently 
only under Catalina), some of our users (only a few, and not me on 
my development machines) end up with toolbar items that have a 
very odd appearance---some are fine, some are completely whited 
out, some are almost completely whited out with some odd colors 
added, usually pale pink in an area which has nothing to do with the 
original icon appearance. The washed out icons have nothing to do 
with them being tagged inactive---on my machine, inactive icons 
look correctly dimmed and the washed out ones are supposed to be 
active anyway. Does anyone have an idea what the problem might 
be?

Best regards,

Tom Doan
Estima
---
2717 Harrison St
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSString drawAtPoint in Mojave

[Tom Doan]

ITOT that the problem was that I had a call to lockFocusIfCanDraw 
in my drawRect handler (from who knows what prior incarnation of 
the OS) which, according to the documentation is deprecated and 
"does nothing and should not be called". The second half of that is 
probably correct, the first half isn't. In the 10.14 SDK, it changed the 
[NSGraphicsContext currentContext] so my text was apparently 
being drawn to nowheresville. Works fine with the 10.13 SDK.


> I just started testing a port of my application to Mojave. I'm having
> a rather odd problem with NSString drawAtPoint withAttributes. I use
> that to add text to graph windows. All the lines and fills look fine,
> but the text, done with drawAtPoint, doesn't show on the screen.
> However, if I take the window and create a PDF from it, everything
> looks fine. It also works fine on High Sierra. Anybody have any idea
> what might be going wrong with this?
> 
> Best regards,
> 
> Tom Doan
> ---
> Estima
> 1560 Sherman Ave #1029
> Evanston, IL 60201
> USA
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/tomd%40estima.com
> 
> This email sent to t...@estima.com


---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSString drawAtPoint in Mojave

[Tom Doan]

> On Nov 7, 2018, at 11:40 AM, Tom Doan  wrote:
> > 
> >> Does the "Layer-Backed Views" section of the AppKit Release Notes
> >> for 10.14 explain what you're seeing?
> >> <https://developer.apple.com/documentation/macos_release_notes/maco
> >> s_m
> >> ojave_10_14_release_notes/appkit_release_notes_for_macos_10_14#3014
> >> 921
> >>> 
> > 
> > I'm not really sure how. As I said, any non-text information seems
> > to be drawn correctly. Why would only the text not get drawn
> > properly?
> 
> Well, are those all drawn in the same view?  Are you perhaps using
> -setNeedsDisplayInRect: with rects for the non-text stuff and
> accidentally relying on an enclosing/overlapping/underlapping view's
> redraw to force the drawing of the text?
> 
I do setNeedsDisplay for the whole view.

> Regards,
> Ken
> 


---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSString drawAtPoint in Mojave

[Tom Doan]

> > 
> > I just started testing a port of my application to Mojave. I'm
> > having a rather odd problem with NSString drawAtPoint
> > withAttributes. I use that to add text to graph windows. All the
> > lines and fills look fine, but the text, done with drawAtPoint,
> > doesn't show on the screen. However, if I take the window and create
> > a PDF from it, everything looks fine. It also works fine on High
> > Sierra. Anybody have any idea what might be going wrong with this?
> 
> Are you just running your app on Mojave or are you also building
> against the 10.14 SDK?

I built it in XCode 10.1. I don't see an option on that to choose the 
SDK---all it shows is "Mac OSX" as the Base SDK.

  Are you able to test a version of your app
> that was built against an earlier SDK?  Does that show the same issue
> when run on Mojave?

If I run a build from before XCode 10.1, it works fine.

> Where/when are you calling -drawAtPoint:withAttributes:?  Is it within
> a view's -drawRect: method?  Or are you trying to draw at some other
> time?

Yes, in the drawRect.
 
> Does the "Layer-Backed Views" section of the AppKit Release Notes for
> 10.14 explain what you're seeing?
>  ojave_10_14_release_notes/appkit_release_notes_for_macos_10_14#3014921
> >

I'm not really sure how. As I said, any non-text information seems to 
be drawn correctly. Why would only the text not get drawn 
properly?

> Regards,
> Ken
> 


---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSString drawAtPoint in Mojave

[Tom Doan]

I just started testing a port of my application to Mojave. I'm having a 
rather odd problem with NSString drawAtPoint withAttributes. I use 
that to add text to graph windows. All the lines and fills look fine, but 
the text, done with drawAtPoint, doesn't show on the screen. 
However, if I take the window and create a PDF from it, everything 
looks fine. It also works fine on High Sierra. Anybody have any idea 
what might be going wrong with this?

Best regards,

Tom Doan
---
Estima
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

runModalSession handling

[Tom Doan]

Based upon a recommendation that I found, I changed up code from running a 
modal dialog to use 
beginModalSessionForWindow and runModalSession. Unfortunately, if I run an 
NSOpenPanel from within this 
(used for a browse for a target directory), runModalSession for *my* dialog 
returns the 0 or 1 off the open panel 
as soon as that closes, thus (with my expected handling) closing my dialog as 
well. I checked and none of my 
stopModalWithCodes are being fired, so the result code has to be coming off the 
system dialog. I did a kludge 
where I used 100 and 101 for my own stop codes, and continued on 0 and 1, and 
that seemed to work around 
this, but I would really like to understand what is wrong with this setup.

Best regards,

Tom Doan
---
1560 Sherman Ave #1029
Evanston, IL 60201
USA




#if 0
//
//  Original code
//
itsRC = (LOGICAL) ([NSApp runModalForWindow:itsDialog->GetDlgWnd()]);
#else
//
//  Code which gives main loop time
//
NSModalSession session = [NSApp 
beginModalSessionForWindow:itsDialog->GetDlgWnd()];
int result = NSModalResponseContinue;

while (result == NSModalResponseContinue)
{
//run the modal session
//once the modal window finishes, it will return a different 
result and break out of the loop
result = [NSApp runModalSession:session];

//this gives the main run loop some time so your other code 
processes
[[NSRunLoop currentRunLoop] 
limitDateForMode:NSDefaultRunLoopMode];

//do some other non-intensive task if necessary
}
[NSApp endModalSession:session];
itsRC = (LOGICAL) (result);
#endif



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSAccessibility

[Tom Doan]

I have a program which uses the Scintilla text editor. When it's run on an OS 
10.8, it gets a crash due to an 
unrecognized selector for setAccessibilityElement (part of log shown at the 
bottom).

The interface for the view that causes the problem is:

@interface SCIContentView : NSView <
  NSTextInputClient,
  NSUserInterfaceValidations,
  NSDraggingSource,
  NSDraggingDestination,
  NSAccessibilityStaticText>;

where it looks like NSAccessibilityStaticText was added with 10.10.

My problem is that setAccessibilityElement is never called explicitly by 
SCIContentView so I don't know how 
to prevent this call from being made. Any suggestions?

Best regards,

Tom Doan
Estima


Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x, 0x

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', 
reason: '-[SCIContentView setAccessibilityElement:]: unrecognized selector sent 
to instance 0x7fcbac051ba0'
terminate called throwing an exception
abort() called

Application Specific Backtrace 1:
0   CoreFoundation  0x7fff85469b06 
__exceptionPreprocess 
+ 198
1   libobjc.A.dylib 0x7fff8b7033f0 objc_exception_throw 
+ 43
2   CoreFoundation  0x7fff8550040a -[NSObject(NSObject) 
doesNotRecognizeSelector:] + 186
3   CoreFoundation  0x7fff8545802e ___forwarding___ + 
414
4   CoreFoundation  0x7fff85457e18 
_CF_forwarding_prep_0 
+ 232
5   RATS0x000101b2786a -[SCIContentView 
initWithFrame:] + 266
6   RATS0x000101b2ac05 -[ScintillaView 
initWithFrame:] + 197


---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSProgressIndicator indeterminate

[Tom Doan]

> On Apr 13, 2017, at 13:35 , Tom Doan <t...@estima.com> wrote:
> > 
> > the indeterminate one has an almost imperceptibly lighter
> > medium-dark moving over medium-dark.
> 
> This suggests you have set your system appearance to Graphite instead
> of Blue (in System Preferences -> General), and it may well be that in
> the graphite version it´s harder to see the animation than in the
> default blue. Your physical environment (lighting conditions, monitor
> age, etc) might also have some effect on what you see. However, it´s
> hard to say whether your users will or will not see the animation.
> 
> IMO, it´s not worth worrying about the problem. Apple has decided
> that this new style of indeterminate progress is suitable, so it´s
> not your fault if they´re wrong. Anything clever you do to change
> the appearance could easily break the next time Apple tweaks control
> appearances.
> 
> If you feel that it´s going to be a problem for users, then you
> could use the spinning version of the indeterminate progress control,
> instead of or in addition to the bar version.

Thanks. I do indeed have Graphite rather than Blue, though Blue is 
same basic problem in Blue. However, the spinning wheel works 
fine, so I switched to that.

---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSProgressIndicator indeterminate

[Tom Doan]

I've been using determinate NSProgressIndicators for years and 
those seem to work fine. I recently added a indeterminate one for a 
particular operation. On first (and second and third) takes, I thought 
it wasn't working. Then I looked *really* closely and found that there 
actually is a *very* slight gradient moving across the bar. While the 
determinate bar is medium-dark gray moving over light gray, the 
indeterminate one has an almost imperceptibly lighter medium-dark 
moving over medium-dark. This seems less than ideal. Is there 
some setting that can change that?

Tom Doan
---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Gestures cause crash in Sierra

[Tom Doan]

ITOT any gesture which could be interpreted as the start of a scroll 
generated an immediate constrainBoundsRect call with +inf,+inf as 
the origin (apparently a bug/feature in Sierra). My custom 
NSClipView wasn't set up to handle the invalid coordinates (it 
generally passes back whatever is sent to it) which causes the 
crash. Replacing the origin with 0.0,0.0 fixes the problem, but that 
doesn't help with our existing software. 

> On Nov 23, 2016, at 13:32 , Tom Doan <t...@estima.com> wrote:
> > 
> > OS Version:Mac OS X 10.12 (16A323)
> 
> I´d suggest you try this on 10.12.1, in case it´s a known problem
> that´s fixed. If not, you should probably go ahead and submit a bug
> report with the exception message and backtrace. In cases like this,
> you´ll often get a "triage" response from Apple within a couple
> of days, telling you what additional information they´d like to see.
> 
> If there´s anything rational to be concluded from the information
> you provided, it´s that the 2- and 3-finger swipe is by default a
> scroll, so is there any chance that your scroll range (content size
> and offset) is excessively large, or messed up in some way that you
> can see?
> 
> 


---
1560 Sherman Ave #1029
Evanston, IL 60201
USA



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Gestures cause crash in Sierra

[Tom Doan]

I'm having a problem with my applications that has come up just 
with Sierra. Any "swiping" gesture with two or three fingers on the 
trackpad causes an immediate crash. (Log below). A four finger 
swipe (if the four fingers are put down very deliberately) behaves 
properly. The fatal thread doesn't include any of my code, so I have 
no idea what's happening. I don't do anything in any of my views to 
handle any of the gestures directly. When I added (for instance) a 
SwipeWithEvent on the view, it never seems to get called. Any help 
with this would be greatly appreciated.

Best regards,

Tom Doan
Estima
---
1560 Sherman Ave #1029
Evanston, IL 60201
USA

Process:   RATSPro [986]
Path:  /Applications/RATS Pro
9.1/RATSPro.app/Contents/MacOS/RATSPro 
Identifier:  
com.estima.rats Version:   9.10.5 (1) Code 
Type:   
X86-64 (Native) Parent Process:    ??? [1] 
Responsible: 
RATSPro [986] User ID:   502

Date/Time: 2016-11-22 11:17:46.241 -0800
OS Version:    Mac OS X 10.12 (16A323)
Report Version:    12
Anonymous UUID:    
7EED464A-4A8E-2079-053C-33A3D31ED801

Sleep/Wake UUID:   
3A646693-9CAC-4B18-A517-C6FAF1D22E3F

Time Awake Since Boot: 6900 seconds

System Integrity Protection: enabled

Crashed Thread:    4  Dispatch queue: NSScreenUpdate

Exception Type:    EXC_CRASH (SIGABRT)
Exception Codes:   0x, 
0x
Exception Note:    EXC_CORPSE_NOTIFY

Application Specific Information:
*** Terminating app due to uncaught exception 
'NSScrolling', reason:
'24332693 bear trap: NSScrollView bad canonicalOrigin 
(NaN) detected!
Please note any info you can in the bug.' terminating with 
uncaught
exception of type NSException abort() called

Application Specific Backtrace 1:
0   CoreFoundation  0x7fff8638a7bb
__exceptionPreprocess + 171 1   
libobjc.A.dylib   
0x7fff9aaf7a2a objc_exception_throw + 48 2   
AppKit  
  0x7fff84212683 
-[_NSScrollingConcurrentSharedData
threadSafePropertyAccess:] + 145 3   
AppKit
0x7fff84214601 
-[_NSScrollingConcurrentEventVBLPreprocessFilter
scrollingVBLMonitor:synchronizeForVBLSerialNumber:times
tamp:updateDuration
:] + 383 4   AppKit  
0x7fff84214414
-[_NSScrollingConcurrentVBLMonitor
_synchronizeForVBLSerialNumber:timestamp:updateDurati
on:] + 535 5   AppKit
 0x7fff8421418d
__42-[_NSScrollingConcurrentVBLMonitor 
resume]_block_invoke + 218 6 
AppKit  0x7fff842140aa
__45-[NSScreen(NSScreenUpdate) 
addUpdateHandler:]_block_invoke_2 + 212 7 
libdispatch.dylib   0x7fff9b39d128
_dispatch_client_callout + 8 8   
libdispatch.dylib 
0x7fff9b3b2c10 _dispatch_continuation_pop + 533 
9   libdispatch.dylib
 0x7fff9b3a8ad2 
_dispatch_source_latch_and_call + 192
10  libdispatch.dylib   0x7fff9b39f966
_dispatch_source_invoke + 1248 11  
libdispatch.dylib 
0x7fff9b3b2a50 _dispatch_continuation_pop + 85 12  
libdispatch.dylib 
    0x7fff9b3a9ea3 
_dispatch_async_redirect_invoke + 734
13  libdispatch.dylib   0x7fff9b39eee0
_dispatch_root_queue_drain + 476 14  
libdispatch.dylib 
0x7fff9b39ecb7 _dispatch_worker_thread3 + 99 15
libsystem_pthread.dylib 0x7fff9b5e9746 
_pthread_wqthread +
1299 16  libsystem_pthread.dylib 
0x7fff9b5e9221
start_wqthread + 13

etc.

(main thread is in the run loop)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSAlert and threading

[Tom Doan]

I have an menu operation which, before it fully executes, pops up 
an NSAlert asking a Yes/No question ("Selection Only(Y/N)?") then, 
depending upon the answer will either apply to the whole list or just 
the selection. However, no matter what I do (other than putting the 
operation in a separate thread), the alert box stays on the screen 
until the operation is done. release doesn't work. orderout on the 
window doesn't work. Is there any way to do this (other than 
changing the threading) so the alert box goes away when I'm done 
with it?

Best regards,

Tom Doan
Estima
---
1560 Sherman Ave #1029
Evanston, IL 60201
USA


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

HIThemeGetTextDimensions problems

[Tom Doan]

While doing some cleanup of memory problems on our software, I 
discovered that HIThemeGetTextDimensions seemed to be leaking memory. 
(At minimum, it seemed to be allocating a CFString and a CFDictionary and 
never fully releasing them). This seems to be an old Carbon-era function 
which is poorly documented and has been a probably even before I found 
that it was leaking. (We have a multi-threaded application and it seems it 
doesn't work properly unless run on the main thread, which never made any 
real sense). Is there a more modern and well-behaved alternative to this? I 
can't seem to find one.


(Code in which it's used)

-(IBAction) textsize:(id) view
{
CGFloat cgwidth;
HIThemeTextInfo textinfo;
textinfo.version = 1;
textinfo.state   = kThemeStateActive;
textinfo.fontID  = kThemeSystemFont;
textinfo.horizontalFlushness = kHIThemeTextHorizontalFlushLeft;
textinfo.verticalFlushness   = kHIThemeTextVerticalFlushCenter;
textinfo.options = 0;
textinfo.truncationPosition  = kHIThemeTextTruncationNone;
textinfo.truncationMaxLines  = 1;
HIThemeGetTextDimensions(itsString,0,,,NULL,NULL);
itsWidth = cgwidth;
}

Best regards,

Tom Doan
Estima
---
1560 Sherman Ave #1029
Evanston, IL 60201
USA

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Problem in notification

[Tom Doan]

I have a user of one of my software programs who has been having all kinds of
problems which I can't seem to reproduce, and have no idea how to even debug 
them.
I include below a traceback that he sent me. This is something that occurs 
almost right
away: launch the program, do File-New, and it is in the process of running a 
modal
dialog which includes an NSScrollView. I have an observer on 
viewContentFrameDidChange
and it's while processing that that it fails. 

So far as I can tell, it shouldn't be where it is. If I run it and set a 
breakpoint on the observer, 
it gets called in a completely different situation---the one that I intended. I 
have no idea what
it's trying to do here. (What's an NSScrollerImp?) and no idea how to trap it 
to figure out 
what the problem is. Any help anyone can offer would be appreciated.

Tom Doan
Estima 




Process: WinTDOSX [359] 
Path: /Applications/WinTD 4.20/WinTDOSX.app/Contents/MacOS/WinTDOSX 
Identifier: com.estima.WinTD 
Version: 4.20 (4.20) 
Code Type: X86-64 (Native) 
Parent Process: launchd [154] 
Responsible: WinTDOSX [359] 
User ID: 501 
Date/Time: 2014-06-10 15:34:56.670 -0400 
OS Version: Mac OS X 10.9.2 (13C1021) 
Report Version: 11 
Anonymous UUID: 15F9A42A-3E8C-7B04-D878-7429EA0F52CF 
Crashed Thread: 0 Dispatch queue: com.apple.main-thread 
Exception Type: EXC_BAD_ACCESS (SIGSEGV) 
Exception Codes: KERN_INVALID_ADDRESS at 0x 
VM Regions Near 0: 
-- 
__TEXT 0001-0001002d3000 [ 2892K] r-x/rwx SM=COW 
/Applications/WinTD 
4.20/WinTDOSX.app/Contents/MacOS/WinTDOSX 
Application Specific Information: 
Performing @selector(respond:) from sender NSMenuItem 0x618af7e0 
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 
0 com.estima.WinTD 0x0001000feadb -[ENSScrollView 
viewContentFrameDidChange:] + 76 
1 com.apple.CoreFoundation 0x7fff8cd2fe0c 
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 
12 
2 com.apple.CoreFoundation 0x7fff8cc238dd _CFXNotificationPost + 2893 
3 com.apple.AppKit 0x7fff874d8193 -[NSView _postFrameChangeNotification] + 
434 
4 com.apple.AppKit 0x7fff874e1852 -[NSView setFrameSize:] + 1586 
5 com.apple.AppKit 0x7fff8750a212 -[NSClipView setFrameSize:] + 380 
6 com.apple.AppKit 0x7fff874e11d9 -[NSView setFrame:] + 294 
7 com.apple.AppKit 0x7fff8750d178 -[NSScrollView _setContentViewFrame:] + 
669 
8 com.apple.AppKit 0x7fff8750cacd -[NSScrollView _applyContentAreaLayout:] 
+ 131 
9 com.apple.AppKit 0x7fff8750b0a4 -[NSScrollView tile] + 1943 
10 com.apple.AppKit 0x7fff87dc0f3e +[NSScrollerImpPair 
_updateAllScrollerImpPairsForNewRecommendedScrollerStyle:] 
+ 401 
11 com.apple.CoreFoundation 0x7fff8cd2fe0c 
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ 
+ 12 
12 com.apple.CoreFoundation 0x7fff8cc238dd _CFXNotificationPost + 2893 
13 com.apple.Foundation 0x7fff944d97ba -[NSNotificationCenter 
postNotificationName:object:userInfo:] + 68 
14 libdispatch.dylib 0x7fff917cc1d7 _dispatch_call_block_and_release + 12 
15 libdispatch.dylib 0x7fff917c92ad _dispatch_client_callout + 8 
16 libdispatch.dylib 0x7fff917d0f03 _dispatch_main_queue_callback_4CF + 333 
17 com.apple.CoreFoundation 0x7fff8ccc85a9 
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 
18 com.apple.CoreFoundation 0x7fff8cc837c4 __CFRunLoopRun + 1636 
19 com.apple.CoreFoundation 0x7fff8cc82f25 CFRunLoopRunSpecific + 309 
20 com.apple.HIToolbox 0x7fff8d025a0d RunCurrentEventLoopInMode + 226 
21 com.apple.HIToolbox 0x7fff8d0257b7 ReceiveNextEventCommon + 479 
22 com.apple.HIToolbox 0x7fff8d0255bc 
_BlockUntilNextEventMatchingListInModeWithFilter + 65 
23 com.apple.AppKit 0x7fff874aa3de _DPSNextEvent + 1434 
24 com.apple.AppKit 0x7fff874a9a2b -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 122 
25 com.apple.AppKit 0x7fff87808e2e -[NSApplication _realDoModalLoop:peek:] 
+ 642 
26 com.apple.AppKit 0x7fff8780754e -[NSApplication runModalForWindow:] + 
117 
27 com.estima.WinTD 0x0001000f6758 EDialog::Process() + 88 
28 com.estima.WinTD 0x00010007c7e0 Tournament::DoNew() + 80 
29 com.estima.WinTD 0x00010007676d PairingsAppl::DoMenuCommand(long) + 235 
30 com.estima.WinTD 0x0001001692b9 -[MenuHandler respond:] + 87 
31 com.apple.AppKit 0x7fff876c8340 -[NSApplication sendAction:to:from:] + 
327 
32 com.apple.AppKit 0x7fff876e32a8 -[NSMenuItem _corePerformAction] + 394 
33 com.apple.AppKit 0x7fff876e2fe4 -[NSCarbonMenuImpl 
performActionWithHighlightingForItemAtIndex:] + 117 
34 com.apple.AppKit 0x7fff8773248d -[NSMenu 
_internalPerformActionForItemAtIndex:] + 35 
35 com.apple.AppKit 0x7fff87732309 -[NSCarbonMenuImpl 
_carbonCommandProcessEvent:handlerCallRef:] + 104 
36 com.apple.AppKit 0x7fff876d90d6 NSSLMMenuEventHandler + 716 
37 com.apple.HIToolbox 0x7fff8cfff1d4 
DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) 
+ 892 
38

Zombie NSWindow

[Tom Doan]

I have an app where one of my window types under certain 
(reproducible) conditions will process the sendEvent for close, I get 
the windowWillClose notification, the window disappears from the 
screen, then somehow reappears when I continue execution as a 
zombie window. It's on the Window menu, but it doesn't respond 
to anything. (For instance, I can't try to close it again.) I've put 
NSLogs in a bunch of places but can't seem to locate what causes 
an apparently dead window to reappear. Any thoughts?

Best regards,

Tom Doan
Estima

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSHelpManager

[Tom Doan]

Thanks for the tips. That *almost* works the way I want. I mapped 
the Help menu item to a doHelp sent to the (custom) application 
class rather than showHelp. The only problem now is that the 
command-? still goes to the help search box. If I then choose the 
WinTD Help item under the search box, it goes through my 
custom help handling and pops up the correct window. I don't see 
how to cut the stop at the search box out of the process---it doesn't 
*look* like the Help is a custom NSMenuItem, but it sure acts like 
one.

Best regards,

Tom Doan
Estima

 On 2014 Apr 25, at 10:38, Tom Doan t...@estima.com wrote:
 
  1. NSHelpManager does not seem to have a way to open up a page based
  upon the file name (just anchors and search strings), while the
  older Apple Help did. Am I missing something there?
 
 I don´t think so.  All my pages begin with, an h1 or h2 etc.,
 which have id attributes, which are good for anchors.
 
  user hits the help keys on a dialog ... opens up the help with the
  specific page for that dialog
 
  2. Under Windows, if you hit the F1 key, WM_HELP messages are 
  sent up the chain, so I just have to process that at the desired
  level. I was hoping that there would similarly be a showHelp in
  NSResponder, but it appears that showHelp always goes straight to
  the NSApplication. Is there any way to work get the type of behavior
  I need?
 
 Don´t use -[NSApplication showHelp:].  Define your own action method
 that you implement in various classes (levels).  Then wire your
 button´s target to this method in First Responder.
 
 By the way, although NSHelpManager is Cocoa,
 apple-help-author...@lists.apple.com is also a resource for this
 stuff.
 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/tomd%40estima.com
 
 This email sent to t...@estima.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSHelpManager

[Tom Doan]

I'm trying to do something with help which I would have hoped 
would be straightforward, but it seems not be so.

I have several applications which are both Windows and Mac. I 
have a help tool (Windows based) which generates a .chm file for 
Windows and a collection of .html files for the Mac. I've been able to 
successfully compile the latter into a Help book. I'm now trying to set 
this up so that if the user hits the help keys on a dialog, it opens up 
the help with the specific page for that dialog. I have a couple of 
problems/questions with this:

1. NSHelpManager does not seem to have a way to open up a page 
based upon the file name (just anchors and search strings), while 
the older Apple Help did. Am I missing something there?

2. Under Windows, if you hit the F1 key, WM_HELP messages are 
sent up the chain, so I just have to process that at the desired level. 
I was hoping that there would similarly be a showHelp in 
NSResponder, but it appears that showHelp always goes straight to 
the NSApplication. Is there any way to work get the type of behavior 
I need?

Best regards,

Tom Doan
Estima

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSButton/NSBox interaction

[Tom Doan]

This is a Cocoa port of a Carbon app (and I also have Windows and 
GTK versions). My code assumes that I'm controlling the radio 
buttons, which has worked fine until now (apparently the 10.8 SDK). 
What I want is a radio style button which turns on when I want it on 
and turns off when I want it off and doesn't go off and manage itself 
along with the other buttons that the OS thinks (incorrectly in this 
case) are logically linked to it.

Tom Doan
Estima

  On Apr 10, 2014, at 6:57 AM, Keary Suska cocoa-...@esoteritech.com
  wrote:
  
  On Apr 9, 2014, at 5:30 PM, Graham Cox wrote:
  
  I'm not exactly certain of the mechanism, but I think radio buttons
  interact as a set through the agency of their immediate superview,
  so if several buttons share it, they are assumed to be part of the
  same set.
  
  So you can embed the separate sets into container views or
  NSMatrix, and they'll work as you want. You mention NOT putting
  them into a NSMatrix for some reason - what reason? That's the
  usual way to set up radios, though it comes with the added
  restriction that the buttons have to be laid out on a regular grid.
  But embedding them in a custom view that draws nothing should also
  work, and that has no such limitation.
  
  
  That would be great functionality that I have often desired but
  AFAICT that is not the case--at least I am unable to replicate it.
  Or do you mean multiple radio-type NSButtonCells in a single view?
  That would make sense but only NSMatrix has that functionality
  built-in, AFAIK.
 
 I think Graham is referring to this feature, added in 10.8:
 
  An NSButton configured as a radio button (with the -buttonType set
  to NSRadioButton), will now operate in a radio button group for
  applications linked on 10.8 and later. To have the button work in a
  radio group, use the same -action for each NSButton instance, and
  have the same superview for each button. When these conditions are
  met, checking one button (by changing the -state to 1), will uncheck
  all other buttons (by setting their -state to 0).
 
 https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKit
 OlderNotes/
 
 Tom, are you sure that your two sets of radio buttons use different
 actions?
 
 --Kyle Sluder
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/tomd%40estima.com
 
 This email sent to t...@estima.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSButton/NSBox interaction

[Tom Doan]

Thanks for the help. Embedding each subset inside a custom view 
did fix the problem. It would certainly have been nice to have the 
NSButton class reference say something about the change, since it 
should have been expected to break at least some existing 
software.

 This is a Cocoa port of a Carbon app (and I also have Windows and GTK
 versions). My code assumes that I'm controlling the radio buttons,
 which has worked fine until now (apparently the 10.8 SDK). What I want
 is a radio style button which turns on when I want it on and turns off
 when I want it off and doesn't go off and manage itself along with the
 other buttons that the OS thinks (incorrectly in this case) are
 logically linked to it.
 
 Tom Doan
 Estima
 
   On Apr 10, 2014, at 6:57 AM, Keary Suska
   cocoa-...@esoteritech.com wrote:
   
   On Apr 9, 2014, at 5:30 PM, Graham Cox wrote:
   
   I'm not exactly certain of the mechanism, but I think radio
   buttons interact as a set through the agency of their immediate
   superview, so if several buttons share it, they are assumed to be
   part of the same set.
   
   So you can embed the separate sets into container views or
   NSMatrix, and they'll work as you want. You mention NOT putting
   them into a NSMatrix for some reason - what reason? That's the
   usual way to set up radios, though it comes with the added
   restriction that the buttons have to be laid out on a regular
   grid. But embedding them in a custom view that draws nothing
   should also work, and that has no such limitation.
   
   
   That would be great functionality that I have often desired but
   AFAICT that is not the case--at least I am unable to replicate it.
   Or do you mean multiple radio-type NSButtonCells in a single view?
   That would make sense but only NSMatrix has that functionality
   built-in, AFAIK.
  
  I think Graham is referring to this feature, added in 10.8:
  
   An NSButton configured as a radio button (with the -buttonType set
   to NSRadioButton), will now operate in a radio button group for
   applications linked on 10.8 and later. To have the button work in
   a radio group, use the same -action for each NSButton instance,
   and have the same superview for each button. When these conditions
   are met, checking one button (by changing the -state to 1), will
   uncheck all other buttons (by setting their -state to 0).
  
  https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppK
  it OlderNotes/
  
  Tom, are you sure that your two sets of radio buttons use different
  actions?
  
  --Kyle Sluder
  ___
  
  Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
  
  Please do not post admin requests or moderator comments to the list.
  Contact the moderators at cocoa-dev-admins(at)lists.apple.com
  
  Help/Unsubscribe/Update your Subscription:
  https://lists.apple.com/mailman/options/cocoa-dev/tomd%40estima.com
  
  This email sent to t...@estima.com
 
 
 ___
 
 Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
 
 Please do not post admin requests or moderator comments to the list.
 Contact the moderators at cocoa-dev-admins(at)lists.apple.com
 
 Help/Unsubscribe/Update your Subscription:
 https://lists.apple.com/mailman/options/cocoa-dev/tomd%40estima.com
 
 This email sent to t...@estima.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSButton/NSBox interaction

[Tom Doan]

I have a dialog which has an NSBox. Inside the NSBox are two 
(separate, but conceptually linked) sets of radio buttons. These are 
just NSButtons with radio style---I haven't (at least intentionally) 
embedded them into an NSMatrix. However, when I select one of 
the buttons from one set, it resets all others in both sets to off so 
somehow it's automatically interpreting all the buttons inside 
the box as a single collection even though that's not my intention. 
However, I can't see anything in the description of either NSButton 
or NSBox that seems to cover this behavior so I can override it. Can 
someone explain what's happening, please?

Thanks,

Tom Doan
Estima

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com