Is there any API for doing the following activities related to code
signing?
- Check that the signature on the running codesigned executable is from the
same company as the signature on a bundle?
OR
- Get the company from the codesigned running executable and
- Get the company from a signature on
I'm trying to understand how Mac OS X actually implements the predefined
objects like NSApplication. Not in detail by function, but where the code
lives. This is by way of understanding what happens if the SDK version
doesn't match the system version. Let's suppose I would like to use an
imaginary
This is largely from memory, so details might be wrong.
Normalisation is an insufficiently known thing to consider when working
with Unicode. (We all know that Unicode is a list of code points
(integers).
Here are some Unicode points for this discussion:
U+0065 "e" Latin Small Letter E
U+00E9
Your report is interesting. I have been following it but may have missed a
part of the discussion, so here is one
thought I had. You say that getting the display name of ~/Documents may
result in a delay. This is localizable, so
that in Portugal (for example) the display name is Documentos. So
Thank you very much for taking the time to build a test and make a reply.
I don't (in general) actually have custom subviews. The clicks were tested
(among other places) in parts of the NSWindow to which I have not
explicitly added content, as well as standard classes like NSBox. I was
suggesting
" Why are you compiling a plugin for 32 bits?" Because plug-ins must match
the host app. In this case the host app's 64 bit version was only released
4 years ago. (The host app is made by a third party).
Older versions of the app run on 10.14 and are still widely used by our
customers. So, while
I believe I may be seeing an effect described in the Cocoa docs for the
rightMouseDown:
method. I am unsure exactly what the docs are saying however. Symptom:
compiled for
64-bits, an unhandled rightMouseDown: is eventually sent to the NSWindow
subclass,
but compiled for 32-bits (and run on
No auto-layout, identical coordinate systems. I found the solution, which
is entirely my fault of course, thanks
to your comment "It sounds like your NSView actually has white space at the
top." For the benefit of future
readers of this thread, here is the solution.
I assumed the underlying
I have having a problem working with NSScrollView. The code is in pieces
all over
the desk at the moment, but I'm asking in case someone recognises the
symptoms,
before I reduce this to a simple test case.
An NSScrollView is made from an NSView containing various NSControls. The
NSView
is fine
" . Cocoa is part of the OS, and changes one very OS release. "
This reminds me of a question which pops up for me every few years in
development. I can't call to mind the last
specific details, but it will happen again.
Let's create an imaginary problem:
* Apple add a new class behaviour to
10 matches
Mail list logo
