Re: cocoa-dev digest, Vol 1 #685 - 15 msgs
Re: cocoa-dev digest, Vol 1 #685 - 15 msgs
- Subject: Re: cocoa-dev digest, Vol 1 #685 - 15 msgs
- From: email@hidden
- Date: Sun, 7 Oct 2001 17:36:34 -0500
it still doesn't work i need other classes to be able to access it.
On Sunday, October 7, 2001, at 03:52 PM, cocoa-dev-
email@hidden wrote:
Send cocoa-dev mailing list submissions to
email@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
or, via email, send a message with subject or body 'help' to
email@hidden
You can reach the person managing the list at
email@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cocoa-dev digest..."
Today's Topics:
1. Re: NSTextView (was: Slightly OT: what about the Services?)
(Ondra Cada)
2. Re: NSTextView (was: Slightly OT: what about the Services?)
(Finlay Dobbie)
3. Re: NSTextView (was: Slightly OT: what about the Services?)
(Andreas Monitzer)
4. variable scopes (email@hidden)
5. Re: variable scopes (Jeff LaMarche)
6. Application memory sizes (Simon Wright)
7. Application icon (Simon Wright)
8. Re: Undo in a Sheet -- no takers? (Mason Mark)
9. Re: variable scopes (Ondra Cada)
10. Re: Well, isn't this tantalizing? (John C. Randolph)
11. Re: Application icon (Andreas Monitzer)
12. Re: Application memory sizes (Finlay Dobbie)
13. Re: Application memory sizes (Greg Titus)
14. Re: Application memory sizes (Simon Wright)
15. Re: Application icon (Simon Wright)
--__--__--
Message: 1
From: Ondra Cada <email@hidden>
Date: Sun, 7 Oct 2001 16:17:12 +0100
To: Andreas Monitzer <email@hidden>
Subject: Re: NSTextView (was: Slightly OT: what about the Services?)
Cc: email@hidden
Reply-To: email@hidden
Andreas,
Andreas Monitzer (AM) wrote at Sun, 7 Oct 2001 14:42:19 +0200:
AM> >TextEdit is not an API, but a Cocoa application;
AM>
AM> They both share the same name:
AM>
http://developer.apple.com/techpubs/macosx/Carbon/text/TextEdit/textedit.
html
Right, but the Carbon toolbox does not fit the original context:
Ondra Cada (OC) wrote at Sun, 7 Oct 2001 12:21:03 +0100:
OC> ...I've tried myself the simplest thing -- the TextEdit's "Open
Selection"
OC> service...
---
Ondra Cada
OCSoftware: email@hidden http://www.ocs.cz
2K Development: email@hidden http://www.2kdevelopment.cz
private email@hidden http://www.ocs.cz/oc
--__--__--
Message: 2
Date: Sun, 7 Oct 2001 17:18:05 +0100
Subject: Re: NSTextView (was: Slightly OT: what about the Services?)
Cc: Andreas Monitzer <email@hidden>, email@hidden
To: email@hidden
From: Finlay Dobbie <email@hidden>
On Sunday, October 7, 2001, at 04:17 pm, Ondra Cada wrote:
Right, but the Carbon toolbox does not fit the original context:
Ondra Cada (OC) wrote at Sun, 7 Oct 2001 12:21:03 +0100:
OC> ...I've tried myself the simplest thing -- the TextEdit's "Open
Selection"
OC> service...
Lots of us with less time than yourself to carry out petty debates read
emails to high-volume lists like this so quickly that we might miss
little bits of information like that, and I have to admit I thought your
e-mail could be misinterpreted as referring to the Carbon TextEdit API.
Let's just call it a misunderstanding and be done with it, eh? :-)
-- Finlay
--__--__--
Message: 3
Date: Sun, 7 Oct 2001 19:14:42 +0200
From: Andreas Monitzer <email@hidden>
Subject: Re: NSTextView (was: Slightly OT: what about the Services?)
Cc: email@hidden
To: email@hidden
On Sunday, October 7, 2001, at 05:17 , Ondra Cada wrote:
Andreas Monitzer (AM) wrote at Sun, 7 Oct 2001 14:42:19 +0200:
AM> >TextEdit is not an API, but a Cocoa application;
AM>
AM> They both share the same name:
AM>
http://developer.apple.com/techpubs/macosx/Carbon/text/TextEdit/textedit.
html
Right, but the Carbon toolbox does not fit the original context:
Ondra Cada (OC) wrote at Sun, 7 Oct 2001 12:21:03 +0100:
OC> ...I've tried myself the simplest thing -- the TextEdit's "Open
Selection"
OC> service...
So what? I explained why TextEdit's (the application) Open Selection
doesn'
t work with Carbon apps: TextEdit (the API) doesn't support it. That's
it.
Replace all occurrences of "TextEdit" in my original mail with "duck"
and
maybe you'll get the message.
andy
--
Discussion forthcoming.
--__--__--
Message: 4
Date: Sun, 7 Oct 2001 13:23:50 -0500
Subject: variable scopes
From: email@hidden
To: email@hidden
ok i know this might have been asked before but how to you make a
variables scope public?thanx in advance
--__--__--
Message: 5
Date: Sun, 7 Oct 2001 11:37:41 -0700
From: Jeff LaMarche <email@hidden>
To: email@hidden, email@hidden
Subject: Re: variable scopes
On Sunday, October 7, 2001, at 11:23 AM, email@hidden wrote:
ok i know this might have been asked before but how to you make a
variables scope public?thanx in advance
The answer to this is found in "Object Oriented Programming and the
Objective C Language" available from Apple's developer website. I would
highly recommend reading it if you're going to do any Cocoa programming.
The following pseudo-code should give you all you need to know for
setting an iVar's scope:
@interface foo : NSObject
{
@private
int myPrivateFoo;
@protected
int myProtectedFoo;
@public
int myPublicFoo;
}
...
@end
--__--__--
Message: 6
Date: Sun, 7 Oct 2001 14:49:34 -0400
Subject: Application memory sizes
From: Simon Wright <email@hidden>
To: email@hidden
When I look at the Mail app in ProcessViewer, under statistics I see...
Virtual: 83,380 kbytes
Resident: 16,056 kbytes
When I look at my Cocoa based app I see...
Virtual: 254,392 kbytes
Resident: 12,768 kbytes
I consider my app to be a _very_ modest one and I am puzzled by these
numbers. Does the Resident number really mean that my app is taking 12
Megabytes? The percentage memory shown in the Process Listing seems to
bear this out. What's more puzzling is the Virtual number - what could
possibly cause my app to show 254 Megabytes here? Is there some PB
setting
that I've overlooked?
Simon
--__--__--
Message: 7
Date: Sun, 7 Oct 2001 14:51:57 -0400
Subject: Application icon
From: Simon Wright <email@hidden>
To: email@hidden
I've followed the guidelines to create an appilcation icon file (.icns)
and have instructed PB to use this file. The Finder shows the proper
icon
in its windows but when I launch my app it is still using the generic
application icon.
Have I missed something?
Simon
--__--__--
Message: 8
Date: Sun, 07 Oct 2001 11:55:45 -0700
From: Mason Mark <email@hidden>
To: Bill Cheeseman <email@hidden>, Cocoa-Dev Mail
<email@hidden>
Subject: Re: Undo in a Sheet -- no takers?
[Snipped original problem description: undo not available in sheets).
--On Sunday, October 7, 2001 10:38 AM -0400 Bill Cheeseman
<email@hidden> wrote:
But is this relevant? -- The release notes for something-or-other,
probably the AppKit, state that one of the "fixes" in Mac OS X 10.1 is
that Cocoa now more strictly enforces the rule that a sheet is
document-modal. It does this, at least in part, by disabling certain
menu
items while a sheet is present in the frontmost document window.
Well, I don't know--I was already on 10.1 when I ran into this issue. If
true, it would be a misguided decision requiring a workaround.
I wonder if they thought undo and redo should not be available while a
sheet is present, since they have no way of knowing whether items in
the
undo and redo stacks could be used to alter the document, in violation
of
the document modality sheet rule. Something to think about, anyway.
Yes, this is something to think about as a developer (at the app level),
but I don't think it is even something to think about at the API level.
Certainly, undo should be available (as in, available for the
application
developer to use if necessary); undo should be possible (and encouraged)
anywhere that the user ever enters text, for one thing.
Thinking along the same lines, if you do succeed in finding a way to
enable the undo menu item, how will you prevent the user from undoing
and
redoing actions that should not be changeable while a document-modal
sheet is present? I suppose you might use a completely separate undo
manager that allows undo and redo only of items in the sheet, and only
while the sheet is up. Interesting problem.
In my case (and, I suspect, in most cases), I want to return a separate
undo manager. All I really want to do is allow the user to undo typing
in a
text field. The undoable actions while the sheet is displayed should
pertain only to the sheet.
However, if an app allows the user to edit some property via a sheet, it
would make sense to commit the action to the model/document object when
the
sheet returns (presumably as a result of the user pressing OK). Then the
document could register its own undo actions at that time, with the
sheet
being already dismissed.
It is questions like this that have made me wonder whether it is ever
appropriate to have text fields and other user controls in a sheet if
they
can change document settings. It's ok in a save panel, I suppose,
because
the file name under which to save a document isn't in the nature of a
document setting that should be undoable.
I think that this is sometimes appropriate. But that's another issue;
even
if nothing related to a document is occurring, there are still many
cases
where undo might be required in a sheet.
My app is one such case. Another case where this functionality is
clearly
desirable (but lacking) is in Project Builder, when you commit a file
using
the SCM menu. You commit, make a few text edits to the log message,
accidentally delete a sentence or two more than you intended...and you
have
to type it again, because Undo is not available.
That is one of those clear flaws in the UI, which is all con and no pro.
That's why I doubt this is some intentional thing Apple did; probably
it is
a side-effect of something else, or a design oversight.
--
Mason Mark
--__--__--
Message: 9
From: Ondra Cada <email@hidden>
Date: Sun, 7 Oct 2001 20:01:17 +0100
To: email@hidden
Subject: Re: variable scopes
Cc: email@hidden
Reply-To: email@hidden
hyperzoanoid,
email@hidden (h) wrote at Sun, 7 Oct 2001 13:23:50 -0500:
h> ok i know this might have been asked before but how to you make a
h> variables scope public?thanx in advance
If by "variable" you mean (as I guess) a property, then try @public. If
you
mean a static variable, then just declare it as extern and define
without any
modifier. If you mean a local variable, then it's impossible.
---
Ondra Cada
OCSoftware: email@hidden http://www.ocs.cz
2K Development: email@hidden http://www.2kdevelopment.cz
private email@hidden http://www.ocs.cz/oc
--__--__--
Message: 10
Date: Sun, 7 Oct 2001 12:04:35 -0700
Subject: Re: Well, isn't this tantalizing?
Cc: email@hidden
To: Drew McCormack <email@hidden>
From: "John C. Randolph" <email@hidden>
On Sunday, October 7, 2001, at 11:42 AM, Drew McCormack wrote:
I also note that CGBase has an
#if defined(__WIN32__)
line in there.
That is interesting. I just did a find, and there are lots of
occurrences of "WIN32" in the Cocoa header files. What does this mean?
Are there plans to port to windows, or is this a throwback to an
earlier period? Anybody know?
In most cases, I'd think it was a throwback, but AFAIK CoreGraphics was
work in progresss when Apple first reneged on offering Yellow Box for
Windows.
-jcr
"I fear all we have done is to awaken a sleeping giant and fill him with
a terrible resolve." -Admiral Isoroku Yamamoto, Dec 7, 1941.
--__--__--
Message: 11
Date: Sun, 7 Oct 2001 21:07:13 +0200
From: Andreas Monitzer <email@hidden>
Subject: Re: Application icon
Cc: email@hidden
To: Simon Wright <email@hidden>
On Sunday, October 7, 2001, at 08:51 , Simon Wright wrote:
I've followed the guidelines to create an appilcation icon file (.icns)
and have instructed PB to use this file. The Finder shows the proper
icon
in its windows but when I launch my app it is still using the generic
application icon.
Have I missed something?
Try rebooting - the dock likes to cache information.
andy
--
Discussion forthcoming.
--__--__--
Message: 12
Date: Sun, 7 Oct 2001 20:07:01 +0100
Subject: Re: Application memory sizes
Cc: email@hidden
To: Simon Wright <email@hidden>
From: Finlay Dobbie <email@hidden>
On Sunday, October 7, 2001, at 07:49 pm, Simon Wright wrote:
I consider my app to be a _very_ modest one and I am puzzled by these
numbers. Does the Resident number really mean that my app is taking 12
Megabytes? The percentage memory shown in the Process Listing seems to
bear this out. What's more puzzling is the Virtual number - what could
possibly cause my app to show 254 Megabytes here? Is there some PB
setting that I've overlooked?
The shared memory is mostly frameworks and things that are loaded once
and shared across the entire system of applications. Cocoa depends on
lots of other frameworks which all have to be loaded. 12MB sounds
roughly OK, expecially when you consider that all your windows are
double-buffered and probably use exorbitant amounts of RAM :-)
-- Finlay
--__--__--
Message: 13
Date: Sun, 7 Oct 2001 12:45:11 -0700
Subject: Re: Application memory sizes
Cc: Simon Wright <email@hidden>, email@hidden
To: Finlay Dobbie <email@hidden>
From: Greg Titus <email@hidden>
On Sunday, October 7, 2001, at 12:07 PM, Finlay Dobbie wrote:
On Sunday, October 7, 2001, at 07:49 pm, Simon Wright wrote:
I consider my app to be a _very_ modest one and I am puzzled by these
numbers. Does the Resident number really mean that my app is taking 12
Megabytes? The percentage memory shown in the Process Listing seems to
bear this out. What's more puzzling is the Virtual number - what could
possibly cause my app to show 254 Megabytes here? Is there some PB
setting that I've overlooked?
The shared memory is mostly frameworks and things that are loaded once
and shared across the entire system of applications. Cocoa depends on
lots of other frameworks which all have to be loaded. 12MB sounds
roughly OK, expecially when you consider that all your windows are
double-buffered and probably use exorbitant amounts of RAM :-)
Finlay is right, but I think his answer deserves a little more
explanation...
The resident and virtual numbers for your app is all memory that is
'mapped' by your application, including memory which may be shared with
any other process on the system. The memory used by the instructions in
the frameworks is shared among all applications using those frameworks.
In the process listing it will look like each app is using a ton of
memory for this, but in fact, it is only in RAM once (at most). Most of
it isn't in RAM at all at any particular moment, but address space is
reserved for it in case your app calls that code and it needs to be
executed (this is the virtual number). Code can be loaded out of the
executable / shared library file on the disk as needed and then
discarded later to be loaded again as needed, so the virtual number in
the process listing doesn't represent space used in the swap file
either. (Code - and other memory mapped files - can be 'swapped' back to
the original location it was loaded from.)
Your window backing store is also shared between your process (which
does the drawing on it) and the Window Server process (which flushes the
buffer to the screen). This is another instance where the process
listing will 'count' the same memory twice. A single full-screen window
on a 1600x1200 millions of colors display will take nearly 2 megabytes
of backing store, so this can add up pretty fast.
So, in short, don't worry too much about these numbers. It's almost all
frameworks and window backing store and there isn't much you can do
about it in your particular app. What you need to worry about is if
these numbers tend to rise over time as you use your application (i.e.
you have memory leaks). Any amounts over the startup numbers are usually
non-shared memory and thus have a much greater impact.
Hope this helps,
-Greg
--__--__--
Message: 14
Date: Sun, 7 Oct 2001 16:42:26 -0400
Subject: Re: Application memory sizes
From: Simon Wright <email@hidden>
To: email@hidden
On Sunday, October 7, 2001, at 03:45 PM, Greg Titus wrote:
So, in short, don't worry too much about these numbers. It's almost all
frameworks and window backing store and there isn't much you can do
about
it in your particular app. What you need to worry about is if these
numbers tend to rise over time as you use your application (i.e. you
have
memory leaks). Any amounts over the startup numbers are usually
non-shared memory and thus have a much greater impact.
Thanks for the clarification Greg. As for memory leaks, absolutely! My
app
in particular could be susceptible since it performs a function
repeatedly,
based on a timer. I have been soak-testing it for a few days now and
monitoring it in Process Viewer (which is what prompted the memory
questions).
I am happy to report, so far, absolutely no memory leaks - more
attributable to Cocoa and Java than to any skill on my part I suspect.
Regards,
Simon
PS: My thoughts are with the the men and women currently attempting to
deal with the terror that threatens our world. I hope they succeed. My
thoughts are also with the innocent men, women and children of
Afghanistan.
For readers of this message around the world, it is my belief and the
belief of everyone of all races, creeds and cultures that I know, that
this activity is most certainly NOT toward the Afghan people - our
brothers and sisters of this global village.
PPS: My apologies for using this list for such purposes.
--__--__--
Message: 15
Date: Sun, 7 Oct 2001 16:48:02 -0400
Subject: Re: Application icon
From: Simon Wright <email@hidden>
To: email@hidden
Thanks, Andreas, that did the trick - OS X has lulled me into thinking I
don't ever need to reboot (or logout/login which is what I did).
Simon
On Sunday, October 7, 2001, at 03:07 PM, Andreas Monitzer wrote:
On Sunday, October 7, 2001, at 08:51 , Simon Wright wrote:
I've followed the guidelines to create an appilcation icon file
(.icns)
and have instructed PB to use this file. The Finder shows the proper
icon in its windows but when I launch my app it is still using the
generic application icon.
Have I missed something?
Try rebooting - the dock likes to cache information.
andy
--
--__--__--
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
End of cocoa-dev Digest