• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa view design considerations
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa view design considerations


  • Subject: Re: Cocoa view design considerations
  • From: john <email@hidden>
  • Date: Tue, 17 May 2005 18:36:56 -0400

Hi Jason,

I'm not sure I totally understand based on your diagrams, but why don't you just add a 6th column (labelled whatever you want) that is only populated when necessary. Such as:

<offset>    <hex>    <opcode>    <info>    <ascii>    <debugging symbol>

(at whatever placement). Perhaps you could have control in the window something like, "Show debugging symbols", which would reveal the extra column in the table view and automatically resize the window appropriately.

I personally wouldn't recommend reusing the <offset> column for the debugging symbols, since each column should display information of the same type (I know debugging symbols are in a way related to the code offset, but I don't think they are close enough).

-- John


Hi,

I'm looking for advice on how exactly I should implement the view for a particular type of listing.  Basically, which class would best suit my needs.  I'd like to have the functionality of NSTableView.  I've written several small apps. using them, bindings and non bindings utilised.  The issue that arises concerns the fact that the output is not strictly uniform.  The program is a disassembler.  If anyone remembers or still uses the CodeEditor in ResEdit they'll know exactly what I'm referring to.  I need output of a form like so:

<offset>    <hex>    <opcode>    <info>    <ascii>
<offset>    <hex>    <opcode>    <info>    <ascii>
<offset>    <hex>    <opcode>    <info>    <ascii>
<offset>    <hex>    <opcode>    <info>    <ascii>

However, if debugging symbols are present then I will use them, so the output would become:

<offset>    <hex>    <opcode>    <info>    <ascii>
<offset>    <hex>    <opcode>  <label>
<offset>    <hex>    <opcode>    <info>    <ascii>
<offset>    <hex>    <opcode>    <info>    <ascii>
<offset>    <hex>    <opcode>    <info>    <ascii>
<offset>    <hex>    <opcode>    <info>    <ascii>
<label>

I could simply place <label> into the cell that would normally contain the <offset>.  The problem with this method is that you would be constantly resizing the column width to see the full text of said label.  Would it be possible to have some form of custom cell that could be inserted when the need arises?  I'm clueless as to how I would go about adding a cell for a situation like this.  What I need is a way to override the column width for just that cell.  Would a custom formatter for that cell be of any help?

I'd prefer the cell approach to allow extra functionality.  Also, I'd like it to be only a single pass to populate all the required cells.  I'm expecting to have to do at least one further pass to setup references and the like.

If anyone has any ideas they'd be greatly appreciated.

I've read nothing on CoreData, it's 10.4 only.  I'd like it to run on 10.3 systems as a minimum.

Thanks in advance.


Jason.
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Cocoa view design considerations (From: xCode <email@hidden>)

  • Prev by Date: Timeout for NSCell's trackMouse:inRect:ofView:untilMouseUp:
  • Next by Date: Re: DidFinishLaunchingNotification vs openFile
  • Previous by thread: Cocoa view design considerations
  • Next by thread: Re: Cocoa view design considerations
  • Index(es):
    • Date
    • Thread