pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] AppKit/__init__.py complexity

[Ronald O. <ous...@ci...>]

On Friday, Feb 28, 2003, at 16:51 Europe/Amsterdam, Just van Rossum 
wrote:

> Bill Bumgarner wrote:
>
>> Nope.  Silly me.  It only takes 13 milliseconds to define all of the
>> informal_protocols on a TiBook 667.
>
> That's indeed not so bad. What worries me more is that they all seem
> hand-rolled. Would it be possible -- in theory at least -- to generate
> them from header files?

Not without giving up at least some functionality. The informal procols 
seem to be defined as categories on NSObject for at least some 
protocols, which should make it possible to generate informal_protocol 
definitions given a list of protocol names.

The current versions of the informal_protocol definitions also list 
whether methods are optional or not, and that cannot be inferred from 
the header files. Not having the additional information wouldn't be too 
bad, I'm sure Cocoa will complain loudly if an object doesn't implement 
the required parts of a protocol.

Ronald

Re: [Pyobjc-dev] AppKit/__init__.py complexity

[Bill B. <bb...@co...>]

On Friday, Feb 28, 2003, at 10:51 US/Eastern, Just van Rossum wrote:
> That's indeed not so bad. What worries me more is that they all seem
> hand-rolled. Would it be possible -- in theory at least -- to generate
> them from header files?

Sure.   It is just a matter of parsing the types of the arguments and 
return values.  The other challenge is to be able to identify which 
methods need to be parsed out and which don't.   In most cases, 
delegate methods and data sources are declared in a category [without 
impelmentation] like....

@interface NSObject(NSTableViewDelegate)
@interface NSObject(NSTableDataSource)

... and, I suppose since they return (void), we ought to also grab some 
of the notification declarations as they effectively act like delegate 
methods (if the delegate implements the standard notification method, 
it'll automatically become an observer of the corresponding 
notification)...

@interface NSObject(NSTableViewNotifications)

A simple grep identifies these delegate declarations:

[bumbox:Frameworks/AppKit.framework/Headers] bbum% grep 'Delegate)' *.h
NSApplication.h:@interface NSObject(NSApplicationDelegate)
NSBrowser.h:@interface NSObject(NSBrowserDelegate)
NSControl.h:@interface NSObject(NSControlSubclassDelegate)
NSDrawer.h:@interface NSObject(NSDrawerDelegate)
NSFontManager.h:@interface NSObject(NSFontManagerDelegate)
NSImage.h:@interface NSObject(NSImageDelegate)
NSLayoutManager.h:@interface NSObject (NSLayoutManagerDelegate)
NSOutlineView.h:@interface NSObject(NSOutlineViewDelegate)
NSSavePanel.h:@interface NSObject(NSSavePanelDelegate)
NSSplitView.h:@interface NSObject(NSSplitViewDelegate)
NSTabView.h:@interface NSObject(NSTabViewDelegate)
NSTableView.h:@interface NSObject(NSTableViewDelegate)
NSText.h:@interface NSObject(NSTextDelegate)
NSTextStorage.h:@interface NSObject (NSTextStorageDelegate)
NSTextView.h:@interface NSObject (NSTextViewDelegate)
NSToolbar.h:@interface NSObject (NSToolbarDelegate)
NSWindow.h:@interface NSObject(NSWindowDelegate)

... and these Notifications:

[bumbox:Frameworks/AppKit.framework/Headers] bbum% grep 
'Notifications)' *.h
NSApplication.h:@interface NSObject(NSApplicationNotifications)
NSComboBox.h:@interface NSObject (NSComboBoxNotifications)
NSControl.h:@interface NSObject(NSControlSubclassNotifications)
NSDrawer.h:@interface NSObject(NSDrawerNotifications)
NSOutlineView.h:@interface NSObject(NSOutlineViewNotifications)
NSTableView.h:@interface NSObject(NSTableViewNotifications)
NSToolbar.h:@interface NSObject (NSToolbarNotifications)
NSWindow.h:@interface NSObject(NSWindowNotifications)

... and these DataSources:

[bumbox:Frameworks/AppKit.framework/Headers] bbum% grep 'DataSource)' 
*.h
NSComboBox.h:@interface NSObject (NSComboBoxDataSource)
NSComboBoxCell.h:@interface NSObject (NSComboBoxCellDataSource)
NSOutlineView.h:@interface NSObject(NSOutlineViewDataSource)
NSTableView.h:@interface NSObject(NSTableDataSource)

In all, we really should consider all methods that are declared as a 
category on NSObject.   In some cases, there will be a default 
implementation within the runtime already tacked onto NSObject thus 
obviating the need for an informal_protocol declaration.

[bumbox:Frameworks/AppKit.framework/Headers] bbum% grep -e 
'@interface.*NSObject.*(.*)' *.h | grep -v DataSource | grep -v 
Delegate | grep -v Notifications
NSAccessibility.h:@interface NSObject (NSAccessibility)
NSApplication.h:@interface NSObject(NSServicesRequests)
NSApplicationScripting.h:@interface NSObject 
(NSApplicationScriptingDelegation)
NSColorPanel.h:@interface NSObject(NSColorPanelResponderMethod)
NSDragging.h:@interface NSObject(NSDraggingDestination)
NSDragging.h:@interface NSObject(NSDraggingSource)
NSFontManager.h:@interface NSObject(NSFontManagerResponderMethod)
NSMenu.h:@interface NSObject(NSMenuValidation)
NSNibLoading.h:@interface NSObject (NSNibAwaking)
NSPasteboard.h:@interface NSObject(NSPasteboardOwner)
NSToolbarItem.h:@interface NSObject (NSToolbarItemValidation)
NSView.h:@interface NSObject(NSToolTipOwner)

The Foundation and other frameworks will also have a handful of similar 
declarations.

b.bum

Re: [Pyobjc-dev] AppKit/__init__.py complexity

[Just v. R. <ju...@le...>]

Bill Bumgarner wrote:

> Nope.  Silly me.  It only takes 13 milliseconds to define all of the 
> informal_protocols on a TiBook 667.

That's indeed not so bad. What worries me more is that they all seem
hand-rolled. Would it be possible -- in theory at least -- to generate
them from header files?

Just

Re: [Pyobjc-dev] shouldSelectRow not working as expected

[<bo...@pa...>]

its working as expected now.

thanks, everyone.

--bob

[Pyobjc-dev] AppKit/__init__.py complexity

[Bill B. <bb...@co...>]

It strikes me that AppKit/__init__.py is executing a lot of code upon 
import that results in a bunch of informal_protocols() being defined 
that will very likely never be used-- even in a complex application.

Nope.  Silly me.  It only takes 13 milliseconds to define all of the 
informal_protocols on a TiBook 667.

Never mind (posting this so that other's don't make the same false 
conclusion).

b.bum

[Pyobjc-dev] informal_protocol

[<bb...@ma...>]

On Friday, Feb 28, 2003, at 07:54 US/Eastern, Ronald Oussoren wrote:
> Yup. Feel free to add this to Lib/AppKit/__init__.py ;-). It should 
> contain all the methods a NSOutlineView delegate can implement.
>
> We should probably add informal_protocol definitions for all delegates 
> in Cocoa.

Yes.   When defining such a thing, there is no need to wrap methods 
where all of the arguments are objects and the return value is an 
object.

Correct?

I'm adding NSOutlineViewDelegate now.

b.bum

Re: [Pyobjc-dev] shouldSelectRow not working as expected

[Ronald O. <ous...@ci...>]

On Friday, Feb 28, 2003, at 12:17 Europe/Amsterdam, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> Right. Does the patch I just checked in solve the problem?
>
> Partly, it seems. However, you _must_ return an int/bool for methods
> that are declared to return a BOOL; when I return None instead I get an
> exception. I assume that's because ObjC can't see the difference 
> between
> a BOOL and a char at the time the conversion happens.

Right. As far as the runtime, and therefore the bridge, is concerned 
BOOL is an alias for 'unsigned char'.

>
> In my PythonBrowser playground I have an inconsitency, though. Two
> methods are supposed to return BOOLs, yet one is part of the
> NSOutlineViewDataSource protocol, the other is an NSOutlineView 
> delegate
> method (is there even a NSOutlineViewDelegate protocol?).

Not yet :-)

>
> class PythonBrowserModel(AutoBaseClass, NSOutlineViewDataSource):
>
>     [..snippo..]
>
>     def outlineView_isItemExpandable_(self, view, item):
>         # part of the NSOutlineViewDataSource protocol,
>         # must return int/bool
>         if item is None:
>             item = self.root
>         return item.isExpandable()
>
>     def outlineView_shouldEditTableColumn_item_(self, view, col, item):
>         # this is a delegate method of NSOutlineView, I _must_ return
>         # None as "NO", any other object as "YES", hence the "or None"
>         # hack.
>         return item.isEditable() or None
>
> I suppose this is not solvable without adding an NSOutlineViewDelegate
> informal protocol?

Yup. Feel free to add this to Lib/AppKit/__init__.py ;-). It should 
contain all the methods a NSOutlineView delegate can implement.

We should probably add informal_protocol definitions for all delegates 
in Cocoa.

>
> Here's a thought: what if the bridge would convert the False bool
> instance to nil? Hm, this would only work with Python 2.3 unless we add
> proper bool support to 2.2 ourselves (btw. plistlib.py contains code
> that does just that, but only for that module).

That would work only by accident. If the bit-pattern of the pointer to 
the (proxy-)object for a true value happened to contain 8 0-bits at the 
right location it would also be interpreted as NO by the objective-C 
side of thinks.

Not that adding a private bool type on Python 2.2 would be bad, it 
would allow for the creation of the right kind of NSNumber for boolean 
values, NSNumbers created using numberWithBool: have a different kind 
of representation in plist files. BTW. Later 2.2 versions introduce 
builtins for True and False, does that also introduce a bool type or 
are these just names for 1 and 0?

Ronald

Re: [Pyobjc-dev] shouldSelectRow not working as expected

[Ronald O. <ous...@ci...>]

On Friday, Feb 28, 2003, at 12:51 Europe/Amsterdam, Just van Rossum 
wrote:

> Just van Rossum wrote:
>
>> Here's a thought: what if the bridge would convert the False bool
>> instance to nil? Hm, this would only work with Python 2.3 unless we
>> add proper bool support to 2.2 ourselves (btw. plistlib.py contains
>> code that does just that, but only for that module).
>
> I just tried, and this indeed works for 2.3 (except I think the #ifdef
> PyObjC_HAVE_PYTHON_BOOL test should be removed, as it does the opposite
> of what I thought it would: PyObjC_HAVE_PYTHON_BOOL is defined when
> Python does _not_ have builtin bool support...).

Oops. I should have paid more attention... PyObjC_HAVE_PYTHON_BOOL 
should be defined only when python does have builtin bool support.

Ronald

Re: [Pyobjc-dev] shouldSelectRow not working as expected

[Just v. R. <ju...@le...>]

Just van Rossum wrote:

> Here's a thought: what if the bridge would convert the False bool
> instance to nil? Hm, this would only work with Python 2.3 unless we
> add proper bool support to 2.2 ourselves (btw. plistlib.py contains
> code that does just that, but only for that module).

I just tried, and this indeed works for 2.3 (except I think the #ifdef
PyObjC_HAVE_PYTHON_BOOL test should be removed, as it does the opposite
of what I thought it would: PyObjC_HAVE_PYTHON_BOOL is defined when
Python does _not_ have builtin bool support...).

Thought about this a bit more: this is not going to work in a useful way
in Python 2.2.

Just

Re: [Pyobjc-dev] shouldSelectRow not working as expected

[Just v. R. <ju...@le...>]

Ronald Oussoren wrote:

> Right. Does the patch I just checked in solve the problem?

Partly, it seems. However, you _must_ return an int/bool for methods
that are declared to return a BOOL; when I return None instead I get an
exception. I assume that's because ObjC can't see the difference between
a BOOL and a char at the time the conversion happens.

In my PythonBrowser playground I have an inconsitency, though. Two
methods are supposed to return BOOLs, yet one is part of the
NSOutlineViewDataSource protocol, the other is an NSOutlineView delegate
method (is there even a NSOutlineViewDelegate protocol?).

class PythonBrowserModel(AutoBaseClass, NSOutlineViewDataSource):

    [..snippo..]

    def outlineView_isItemExpandable_(self, view, item):
        # part of the NSOutlineViewDataSource protocol,
        # must return int/bool
        if item is None:
            item = self.root
        return item.isExpandable()

    def outlineView_shouldEditTableColumn_item_(self, view, col, item):
        # this is a delegate method of NSOutlineView, I _must_ return
        # None as "NO", any other object as "YES", hence the "or None"
        # hack.
        return item.isEditable() or None

I suppose this is not solvable without adding an NSOutlineViewDelegate
informal protocol?

Here's a thought: what if the bridge would convert the False bool
instance to nil? Hm, this would only work with Python 2.3 unless we add
proper bool support to 2.2 ourselves (btw. plistlib.py contains code
that does just that, but only for that module).

Just

Re: [Pyobjc-dev] shouldSelectRow not working as expected

[Ronald O. <ous...@ci...>]

On Friday, Feb 28, 2003, at 09:52 Europe/Amsterdam, Just van Rossum 
wrote:

> I think this is a bug.

Right. Does the patch I just checked in solve the problem?

Ronald

Re: [Pyobjc-dev] shouldSelectRow not working as expected

[Just v. R. <ju...@le...>]

Bob Pasker wrote:

> good suggestion. i enabled column selection in IB, and this delegate 
> method still
> runs and still permits column selecting.
> 
>      def tableView_shouldSelectTableColumn_(self, aTableView, 
> aTableColumn):
>          print "select table?"
>          return 0==1

I've seen similar things: the only way I could force a false BOOL value
was to return None. I think this is a bug.

Just

Re: [Pyobjc-dev] shouldSelectRow not working as expected

[<bo...@pa...>]

Hi Chris,

good suggestion. i enabled column selection in IB, and this delegate 
method still
runs and still permits column selecting.

     def tableView_shouldSelectTableColumn_(self, aTableView, 
aTableColumn):
         print "select table?"
         return 0==1

i think there's something wrong with the call linkages for boolean 
return types, but
i can't figure out what it is. if anybody else can get this to actually 
work on
TableModel2,  i'd be interested to know how.

--bob

On Thursday, February 27, 2003, at 07:17 PM, Chris Ryland wrote:

> Bob--
>
> Perhaps the BOOL return value is really what's needed, so you need to 
> return YES or NO?
>
> On Thursday, February 27, 2003, at 07:52  PM, Bob Pasker wrote:
>>     def tableView_shouldSelectRow_(self, aTableView, rowIndex):
>> 		print "shouldSelectRow %d is %d" % (rowIndex, rowIndex % 2)
>>          return rowIndex % 2
>
> Try
>
>             return (rowIndex % 2) == 1
>
> which should normalize to a true boolean value, or, perhaps more 
> safely (is it necessary?),
>
>             if (rowIndex % 2) == 1
>                 return YES
>             else
>                 return NO
>
> (or, if the latest conditional expression PEP gets approved ;-),
>
>             return if (rowIndex % 2 == 1): YES else: NO
>
> Cheers!
> --Chris Ryland / Em Software, Inc. / www.emsoftware.com
>

Re: [Pyobjc-dev] tableview_willDisplayCell_forTableColumn_row_ failure

[<bb...@ma...>]

The developer that hosed it in the first place just committed the 
change as requested.   Sorry about that.

On Thursday, Feb 27, 2003, at 18:09 US/Eastern, Bob Pasker wrote:
> since i don't have write permissions to the CVS depot, can one of
> the developers add this in?

Re: [Pyobjc-dev] shouldSelectRow not working as expected

[Chris R. <cp...@em...>]

Bob--

Perhaps the BOOL return value is really what's needed, so you need to 
return YES or NO?

On Thursday, February 27, 2003, at 07:52  PM, Bob Pasker wrote:
>     def tableView_shouldSelectRow_(self, aTableView, rowIndex):
> 		print "shouldSelectRow %d is %d" % (rowIndex, rowIndex % 2)
>          return rowIndex % 2

Try

             return (rowIndex % 2) == 1

which should normalize to a true boolean value, or, perhaps more safely 
(is it necessary?),

             if (rowIndex % 2) == 1
                 return YES
             else
                 return NO

(or, if the latest conditional expression PEP gets approved ;-),

             return if (rowIndex % 2 == 1): YES else: NO

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com

[Pyobjc-dev] shouldSelectRow not working as expected

[<bo...@pa...>]

well, my tableview_shouldSelectRow is being called, but somehow the
return value is getting ingored on the way back to the TableView.

here's my delegate code, which hopes to make every other row selectable.
it prints the results, but every row in the table is still selectable.
changing it to return 0 doesnt help.

     def tableView_shouldSelectRow_(self, aTableView, rowIndex):
		print "shouldSelectRow %d is %d" % (rowIndex, rowIndex % 2)
          return rowIndex % 2

so, i made the same change to TableModel2, and that didn't produce
the expected behavior, either.

then, i took this sample objC NSTableView code

	http://www.macdevcenter.com/pub/a/mac/2002/08/27/cocoa.html

wired up the controller as a delegate and added

- (BOOL)tableView:(NSTableView *)aTableView 
shouldSelectRow:(int)rowIndex
{
     if (rowIndex % 2) {
         return YES;
     } else {
         return NO;
     }
}

and this of course works correctly.

any ideas?

--bob

Re: [Pyobjc-dev] tableview_willDisplayCell_forTableColumn_row_ failure

[<bo...@pa...>]

ok, i figured it out. the signature for this method was wrong in file

	./Lib/AppKit/__init__.py

line 577 should be changed from
     signature='c@:@@@i',
instead of
     signature='v@:@@@i',

the method was being called, but the bridge was having a hard time
converting my void return to a character (BOOL) return value.

since i don't have write permissions to the CVS depot, can one of
the developers add this in?

--bob

On Thursday, February 27, 2003, at 02:41 PM, Bob Pasker wrote:

> so, when i add the following method to my TableView delegate
>
>     def tableView_willDisplayCell_forTableColumn_row_(self, 
> aTableView, aCell, aColumn, rowIndex):
>         print "tableview will display cell"
>
> the run window shows:
>
>    tableview will display cell
>    Traceback (most recent call last):
>      File "/Users/rbp/Documents/build 
> projects/X.app/Contents/Resources/__main__.py", line 19, in ?
>        sys.exit(AppKit.NSApplicationMain(sys.argv))
>    objc.error: depythonifying 'char', got NoneType of -1
>
> that last line is coming from ./Modules/objc/obj_support.m lines 
> 853:855
>
> the weird thing is that the print results show up in the Run window, 
> so the
> method must be getting called. commenting out the two lines, and the 
> failure
> doesnt happen.
>
> any ideas?
>
> thanks, bob
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] tableview_willDisplayCell_forTableColumn_row_ failure

[<bo...@pa...>]

so, when i add the following method to my TableView delegate

     def tableView_willDisplayCell_forTableColumn_row_(self, aTableView, 
aCell, aColumn, rowIndex):
         print "tableview will display cell"

the run window shows:

    tableview will display cell
    Traceback (most recent call last):
      File "/Users/rbp/Documents/build 
projects/X.app/Contents/Resources/__main__.py", line 19, in ?
        sys.exit(AppKit.NSApplicationMain(sys.argv))
    objc.error: depythonifying 'char', got NoneType of -1

that last line is coming from ./Modules/objc/obj_support.m lines 853:855

the weird thing is that the print results show up in the Run window, so 
the
method must be getting called. commenting out the two lines, and the 
failure
doesnt happen.

any ideas?

thanks, bob

Re: [Pyobjc-dev] enumerator support

[<bo...@pa...>]

thanks, this helped alot. the key was sys.path, which showed the  
difference:

for PB:
['/System/Library/Frameworks/Foundation.framework/Versions/C/ 
Resources', '/Users/rbp/Documents/build  
projects/Mbox2AB.app/Contents/Resources', '/Users/rbp/Documents/build  
projects/Mbox2AB.app/Contents/Resources', '/usr/lib/python2.2',  
'/usr/lib/python2.2/plat-darwin', '/usr/lib/python2.2/lib-tk',  
'/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages']

command line:
['', '/sw/lib/python2.2', '/sw/lib/python2.2/plat-darwin',  
'/sw/lib/python2.2/lib-tk', '/sw/lib/python2.2/lib-dynload',  
'/sw/lib/python2.2/site-packages',  
'/sw/lib/python2.2/site-packages/PyObjC']

--bob


On Thursday, February 27, 2003, at 11:39 AM, Bill Bumgarner wrote:

> On Thursday, Feb 27, 2003, at 13:55 US/Eastern, Bob Pasker wrote:
>> ok, this works in a command-line program (% python test.py), but  
>> doesnt
>> work inside PB. is there a way to see which version of python is being
>> launched by PB? and how to change it? thanks, bob
>
> Sure.  Add something like...
>
> import sys
> print sys.version
>
> .... to __main__.py.
>
> It sounds like you probably have a non-Apple build of Python  
> installed?  If you do, that is fine -- if you plan on using it all the  
> time, I would recommend 'rm -rf  
> /usr/lib/python2.2/site-packages/...pyobjc stuff...' to avoid  
> confusion.
>
> In any case, you can launch one of the Project Template created  
> projects with an alternative python binary by changing the  
> PythonBinPath default.
>
> I do this in PBX by editing the executable and adding...
>
>     -PythonBinPath /usr/local/bin/python
>
> ... as a launch argument.
>
> b.bum
>
>

Re: [Pyobjc-dev] sigbus with TableView delegates

[<bb...@ma...>]

Did you declare your table data source or table delegate as a class 
that implements NSTableDataSource or NSTableViewDelegate?

If not, the problem is that PyObjC has no way of knowing that your 
implementation of said method should take, say, an integer for the 
rowIndex argument vs. an object.  It assumes object and interprets the, 
say, row 1 index as an object pointer -- *boom*.

I.e.:

class TableFoo(SuperFoo, NSTableDataSource):
     .... implement methods ...

Ahhh... there is no NSTableViewDelegate.   Now there is.  Update from 
cvs and rebuild... then declare your class as:


class TableFoo(SuperFoo, NSTableDataSource, NSTableViewDelegate):
     .... implement methods ...

I updated the TableModel2 example to demonstrate the use of 
tableView_shouldSelectRow_().

b.bum

On Thursday, Feb 27, 2003, at 14:17 US/Eastern, Bob Pasker wrote:
> both of these methods are generating a sigbus. the first one fails
> instantly, the second one prints out "tableview will display cell"
> 3 times (in a 4x3 TableModel) and fails. any ideas? --bob
>
>     #
>     # TableView delegate methods
>     #
>     def tableView_shouldSelectRow_(self, aTableView, rowIndex):
>         	print "tableview select row"
> 		return 1
>
>     def tableView_willDisplayCell_forTableColumn_row_(self, 
> aTableView, aCell, aColumn, rowIndex):
>         print "tableview will display cell"

Re: [Pyobjc-dev] enumerator support

[Bill B. <bb...@co...>]

On Thursday, Feb 27, 2003, at 13:55 US/Eastern, Bob Pasker wrote:
> ok, this works in a command-line program (% python test.py), but doesnt
> work inside PB. is there a way to see which version of python is being
> launched by PB? and how to change it? thanks, bob

Sure.  Add something like...

import sys
print sys.version

.... to __main__.py.

It sounds like you probably have a non-Apple build of Python installed? 
  If you do, that is fine -- if you plan on using it all the time, I 
would recommend 'rm -rf /usr/lib/python2.2/site-packages/...pyobjc 
stuff...' to avoid confusion.

In any case, you can launch one of the Project Template created 
projects with an alternative python binary by changing the 
PythonBinPath default.

I do this in PBX by editing the executable and adding...

     -PythonBinPath /usr/local/bin/python

... as a launch argument.

b.bum

[Pyobjc-dev] sigbus with TableView delegates

[<bo...@pa...>]

both of these methods are generating a sigbus. the first one fails
instantly, the second one prints out "tableview will display cell"
3 times (in a 4x3 TableModel) and fails. any ideas? --bob


     #
     # TableView delegate methods
     #
     def tableView_shouldSelectRow_(self, aTableView, rowIndex):
         	print "tableview select row"
		return 1

     def tableView_willDisplayCell_forTableColumn_row_(self, aTableView, 
aCell, aColumn, rowIndex):
         print "tableview will display cell"

Re: [Pyobjc-dev] enumerator support

[<bo...@pa...>]

ok, this works in a command-line program (% python test.py), but doesnt
work inside PB. is there a way to see which version of python is being
launched by PB? and how to change it? thanks, bob


On Thursday, February 27, 2003, at 10:45 AM, Bill Bumgarner wrote:

> It is in the version in CVS.   Specifically, this...
>
>         for aRow in self.typesTable.selectedRowEnumerator():
> 		    ....
>
> ... works just fine nowadays.
>
> Basically, anything that implements -nextObject can be used on the RHS 
> of the 'in' in an iterative context.
>
> b.bum
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] enumerator support

[Bill B. <bb...@co...>]

It is in the version in CVS.   Specifically, this...

         for aRow in self.typesTable.selectedRowEnumerator():
		    ....

... works just fine nowadays.

Basically, anything that implements -nextObject can be used on the RHS 
of the 'in' in an iterative context.

b.bum

Re: [Pyobjc-dev] status of enumerators?

[<bo...@pa...>]

fyi, this is the work-around:

     def addToABAction_(self, sender):
         print "addToABAction"
         selectedRows =  
self.theTableView.selectedRowEnumerator().allObjects()
         for r in selectedRows:
             print "row " + r.stringValue()