OK, the methods -(void)removeSubview: and -(void)viewWillMoveToWindow: release
the memory too, or just remove the objects from the receiver?, is there a way to
see how my app handle the memory?

Hello again,

you write "As far as I remember there is no special handling for printing in NSTableView that would switch off the header."

Are your sure? I have not looked at the source code, but there must be special code to handle tables in scroll views. The header view needs to always stay in place instead of scrolling out of sight. If you look carefully you see that that is no ordinary table view inside the scroll view. It is separated from the header, which is above the scrolling area.

Have I got this right?

Marko

+-------------------------------------------------------------+
| Marko Riedel, EDV Neue Arbeit gGmbH, markoriedelde@yahoo.de |
| http://www.geocities.com/markoriedelde/index.html |
+-------------------------------------------------------------+

--- Fred Kiefer schrieb am Do, 24.7.2008:

Hi there,

just a quick reply -- I'm in a hurry. Thanks for all your help so far.

I am definitely certain that I have the right rectangle. (I am using [table bounds].) Your suggestion re. the superview is tricky. It's a clip view inside a scroll view. It does include the header in its EPS, but it only prints the visible portion (which depends on how the user has sized tbe window).

Best regards,

+-------------------------------------------------------------+
| Marko Riedel, EDV Neue Arbeit gGmbH, markoriedelde@yahoo.de |
| http://www.geocities.com/markoriedelde/index.html |
+-------------------------------------------------------------+

--- Fred Kiefer schrieb am Do, 24.7.2008:

Marko Riedel wrote:

Not sure why this should happen, are you certain to pass in the correct
rectangle? As far as I remember there is no special handling for
printing in NSTableView that would switch off the header.
What you could always try is to print a super view of the table, that
definitly should include everything.

Hello there,

thanks for your reply. I tried your suggestion and ran into a problem: the table does not include the table header in the data for dataWithEPSInsideRect: So I had to get those data separately, but I don't know how to merge them properly. If I just concatenate them, then the bounding box for the whole is wrong and the header obscures part of the first row.

The previous version (the one you commented on) uses ImageMagick to create a PS file for printing. It looks like I won't be able to avoid using it after all. I could assemble the two EPS files (header + table) using Magick, but then I may as well stay with the old approach.

So I guess I will try to find out how to flip views properly so that the rows do not show up in reverse when I draw into a bitmap.

What's your take on this? Of course if I could get header + table in one EPS file, that would be very nice.

Best regards,

+-------------------------------------------------------------+
| Marko Riedel, EDV Neue Arbeit gGmbH, markoriedelde@yahoo.de |
| http://www.geocities.com/markoriedelde/index.html |

David Chisnall writes:

Yes. This was indeed my problem.

Now I am clear on that.

Yes. This is where I misunderstood David Ayers.

Hi,

I remember a while Andreas reported an issue when remote displaying a
GNUstep app on a platform of with different endians (or whatever the
grammatically correct variant of that phrase is). My MBP is
currently broken, so I'm back on my PowerBook and experiencing the
same issue. Using X forwarding from my (PowerPC, big-endian)
PowerBook to my ThinkPad (x86, little-endian) I get strange colours.
It seems something in the Cairo back end (I don't have any of the
others installed anymore, so I can't test if this is a local issue)
is not setting the byte order correctly.

On the plus side, apart from the blue tint, remote GNUstep
performance seems to have improved dramatically. Last time I tried
it, it was almost unusable on a local network with GigE. Now I'm
using it between two machines on an 802.11g network and it's quite
usable (enough lag that you can tell that it's not local, but not
enough to actually be irritating). Many, many thanks to whoever
fixed the latency issues. It is still redrawing a lot more than it
needs to, but this X Server doesn't implement XDamage, so it might be
a server issue.

On 24.07.2008, at 10:20, Charles philip Chan wrote:

^^^ ^^^^^

...

^^^^

Dictionary keys are never NSMutableString objects. As David says, the
NSMutableString will get copied when its used as a dictionary key.

On 24 Jul 2008, at 09:20, Charles philip Chan wrote:

I think the problem is that you are misunderstanding the Objective-C
type system. The type of an object is a property of the object
itself, not of the label of the object (as it is in languages like C+
+, modulo structural typing).

When you insert an object into a dictionary, the key will be
immutable, the object may be mutable. When you call
allKeysForObject: you get an NSArray (immutable) containing pointers
to NSStrings (also immutable). You can not 'return it as an
NSMutableString,' you return it as an id, because that is what the
objectAtIndex: method on NSArray returns.

When you do something like this:

David Ayers fsfe.org> writes:

Hello David:

I still don't understand this, the method "allKeysForObject" is supposed
to:

,----
| Returns an array containing all the dictionary's keys that are
| associated with anObject.[1]
`----

So basically I am returning an array of the keys, and since there is
only 1 key for the object "Album" I search for it at index zero in the
array and return it as an NSMutableString. I then want to change the
string to the really key for the "Album" title and search the dictionary
for the object- I am not even touching the dictionary. Also
"playingItem" is defined as mutable: