Re: Windows and Camelbones
On Aug 20, 2004, at 3:00 PM, Sherm Pendley wrote:
On Aug 20, 2004, at 5:30 PM, Alan Olsen wrote:
On Aug 20, 2004, at 1:34 PM, Sherm Pendley wrote:
my $row =
NSApplication->sharedApplication()->runModalForWindow($self-
>myPanel());
How do you set the datasource for tableview. I usually call it right
after displaying the window. I am not certain what procedure to put
it in since there is not a constructor for the window that I am aware
of.
Are you asking when to call setDatasource:? Whenever you want.
You could do it in the controller class' constructor - the "MyPanel"
outlet is connected when you load the .nib, even if the window is
offscreen. The table view won't actually call the data source methods
until it actually needs to display data; i.e. when the window its in
appears onscreen.
You could delay it until just before calling runModalForWindow().
You could make the controller the delegate of MyPanel, and implement
the NSWindow delegate method windowDidBecomeKey:. (Careful if you do
this though; the controller is also the delegate of the main window,
so in the delegate method, you'll have to check *which* window became
key.)
You could create a separate object, and assign it to be both the
datasource and the delegate of MyPanel in the controller's
constructor. It could initially be empty, and fill and/or empty itself
in response to the windowDidBecomeKey: and windowDidResignKey:
delegate methods.
You could do it in Interface Builder. Double-click the scroll view to
select the table view inside it, then control-drag a connection from
it to "File's Owner" and select the "datasource" outlet.
Believe it or not, I actually got it working!
I had to move back to my previous code and then extrapolate what was
going on.
At some point I will post the code that i came up with. (After I clean
it up so it does not look so Gordian knot-like.)
The call to runModalForWindow: won't return until the modal session
is stopped with stopModal, stopModalWithCode:, or abortModal. Let's
assume you want it to return the selected row in TableView. In the
action handler for the OK button, you'd have something like this:
sub okClicked : Selector(okClicked:) ArgTypes(@) ReturnType(v) {
my ($self, $sender) = @_;
my $rowSel = $self->tableView()->selectedRow();
NSApplication->sharedApplication()->stopModalWithCode($rowSel);
}
This does not want to kill the window. I am looking for the
description in the api docs. It looks like it is missing a reference
to what window needs to be destroyed.
It closes whatever window is running modally. Since, by definition,
only one window can be running modally at any given time, there's no
need to refer to a specific window.
Actually it appears to break the modal loop, not close the window. I
just close the window before that and everything is happy.
Re: Windows and Camelbones
This is probably for Sherm-
I am trying to open a non-modal NSOpenPanel. As a simple test, I
modified the CamelBones FileViewer:
$openPanel->beginForDirectory_file_types_modelessDelegate_didEndSelector_contextInfo(
$self->{'_openPath'}, '', $fileTypes, $self,
'openPanelDidEnd:returnCode:contextInfo:', undef
);
When invoked, the panel flashes on screen and disappears. It does not
invoke the end selector.
Is this a bug in my understanding/implementation or camelbones? or
is something else broken (FWIW, OSX 1.3.5)
tia,
rick
Re: Windows and Camelbones
On Aug 20, 2004, at 5:30 PM, Alan Olsen wrote:
On Aug 20, 2004, at 1:34 PM, Sherm Pendley wrote:
my $row =
NSApplication->sharedApplication()->runModalForWindow($self-
>myPanel());
How do you set the datasource for tableview. I usually call it right
after displaying the window. I am not certain what procedure to put
it in since there is not a constructor for the window that I am aware
of.
Are you asking when to call setDatasource:? Whenever you want.
You could do it in the controller class' constructor - the "MyPanel"
outlet is connected when you load the .nib, even if the window is
offscreen. The table view won't actually call the data source methods
until it actually needs to display data; i.e. when the window its in
appears onscreen.
You could delay it until just before calling runModalForWindow().
You could make the controller the delegate of MyPanel, and implement
the NSWindow delegate method windowDidBecomeKey:. (Careful if you do
this though; the controller is also the delegate of the main window, so
in the delegate method, you'll have to check *which* window became
key.)
You could create a separate object, and assign it to be both the
datasource and the delegate of MyPanel in the controller's constructor.
It could initially be empty, and fill and/or empty itself in response
to the windowDidBecomeKey: and windowDidResignKey: delegate methods.
You could do it in Interface Builder. Double-click the scroll view to
select the table view inside it, then control-drag a connection from it
to "File's Owner" and select the "datasource" outlet.
The call to runModalForWindow: won't return until the modal session
is stopped with stopModal, stopModalWithCode:, or abortModal. Let's
assume you want it to return the selected row in TableView. In the
action handler for the OK button, you'd have something like this:
sub okClicked : Selector(okClicked:) ArgTypes(@) ReturnType(v) {
my ($self, $sender) = @_;
my $rowSel = $self->tableView()->selectedRow();
NSApplication->sharedApplication()->stopModalWithCode($rowSel);
}
This does not want to kill the window. I am looking for the
description in the api docs. It looks like it is missing a reference
to what window needs to be destroyed.
It closes whatever window is running modally. Since, by definition,
only one window can be running modally at any given time, there's no
need to refer to a specific window.
sherm--
Re: Windows and Camelbones
On Aug 20, 2004, at 1:34 PM, Sherm Pendley wrote:
On Aug 20, 2004, at 3:31 PM, Alan Olsen wrote:
I am opening it as a modal dialog box. What I am trying to do is get
it to act like "OpenPanel" or the alert dialog. Those return to the
calling process when they are done and not before.
That *is* how a modal session acts. For example, let's assume a panel
that's connected to the outlet named MyPanel. In that panel you have a
table view named TableView. In some action method, you open the panel
like this:
my $row =
NSApplication->sharedApplication()->runModalForWindow($self-
>myPanel());
How do you set the datasource for tableview. I usually call it right
after displaying the window. I am not certain what procedure to put it
in since there is not a constructor for the window that I am aware of.
The call to runModalForWindow: won't return until the modal session is
stopped with stopModal, stopModalWithCode:, or abortModal. Let's
assume you want it to return the selected row in TableView. In the
action handler for the OK button, you'd have something like this:
sub okClicked : Selector(okClicked:) ArgTypes(@) ReturnType(v) {
my ($self, $sender) = @_;
my $rowSel = $self->tableView()->selectedRow();
NSApplication->sharedApplication()->stopModalWithCode($rowSel);
}
This does not want to kill the window. I am looking for the description
in the api docs. It looks like it is missing a reference to what
window needs to be destroyed.
It does act as it should, however.
If you need to do something more complex, like return a string or
object, just store it in an instance variable and use stopModal
instead of returning it directly with stopModalWithCode.
I have tried waiting in a loop until a message comes back, but that
gives me the technicolor pizza.
Like I said, that's by design. If you're spinning in a tight loop,
you're not responding to events, and that means pizza.
Mmmm... Pizza
Re: DBI and Multi-threaded Perl
On Aug 20, 2004, at 4:44 PM, Charlie Minow wrote: *** You are using a perl configured with threading enabled. *** You should be aware that using multiple threads is *** not recommended for production environments. I've looked around and can't find an explanation of what this really means. Does it, for example, mean that eventually DBI will consume all the RAM and kill the server? Or that it'll crash? All I have been able to find so far is that it's not recommended. "Not recommended" is *usually* geek-speak for "We haven't proved it will work." However, absence of proof is not proof of absence. It's not guaranteed to work - but it's not guaranteed to crash either. (Usually - DBI *might* be a guaranteed crasher. I haven't tried it.) Given the nature of the module, I'd say that the most likely result of a problem would be data corruption. I pretty much understand what they mean by "mulitple threads", but I just want to know what would happen if I installed it anyway There's no danger in installing it, or in using it in a single-threaded script, even though your Perl is multi-threading capable. The warning is about using DBI in a multi-threaded script. sherm--
DBI and Multi-threaded Perl
Hi, In trying to set up DBI for Perl under Panther, I get this message: *** You are using a perl configured with threading enabled. *** You should be aware that using multiple threads is *** not recommended for production environments. I've looked around and can't find an explanation of what this really means. Does it, for example, mean that eventually DBI will consume all the RAM and kill the server? Or that it'll crash? All I have been able to find so far is that it's not recommended. I pretty much understand what they mean by "mulitple threads", but I just want to know what would happen if I installed it anyway charlie
Re: Windows and Camelbones
On Aug 20, 2004, at 3:31 PM, Alan Olsen wrote:
I am opening it as a modal dialog box. What I am trying to do is get
it to act like "OpenPanel" or the alert dialog. Those return to the
calling process when they are done and not before.
That *is* how a modal session acts. For example, let's assume a panel
that's connected to the outlet named MyPanel. In that panel you have a
table view named TableView. In some action method, you open the panel
like this:
my $row =
NSApplication->sharedApplication()->runModalForWindow($self-
>myPanel());
The call to runModalForWindow: won't return until the modal session is
stopped with stopModal, stopModalWithCode:, or abortModal. Let's assume
you want it to return the selected row in TableView. In the action
handler for the OK button, you'd have something like this:
sub okClicked : Selector(okClicked:) ArgTypes(@) ReturnType(v) {
my ($self, $sender) = @_;
my $rowSel = $self->tableView()->selectedRow();
NSApplication->sharedApplication()->stopModalWithCode($rowSel);
}
If you need to do something more complex, like return a string or
object, just store it in an instance variable and use stopModal instead
of returning it directly with stopModalWithCode.
I have tried waiting in a loop until a message comes back, but that
gives me the technicolor pizza.
Like I said, that's by design. If you're spinning in a tight loop,
you're not responding to events, and that means pizza.
sherm--
Re: Windows and Camelbones
On Aug 19, 2004, at 10:21 PM, Sherm Pendley wrote: On Aug 19, 2004, at 3:21 PM, Alan Olsen wrote: This is probably a modal v.s. non-modal issue. I want to find out the right way to do it... I have a window that I display that has a table view. The user needs to select a row off the table. The problem is that the window is displayed and then the program just keeps on going and does not wait for anything to return. That's by design. You don't want your program to stop responding to events. If it does, you'll get a "technicolor pizza" cursor after a few seconds. I am opening it as a modal dialog box. What I am trying to do is get it to act like "OpenPanel" or the alert dialog. Those return to the calling process when they are done and not before. I have tried waiting in a loop until a message comes back, but that gives me the technicolor pizza.
Re: Forking & Signals
Now if we take that same simple program and either
don't define $SIG{'TERM'} or set it to 'DEFAULT' we
get END when the parent dies, but when we kill the
child &cleanup isn't run (duh) but neither is END. Is
that standard behaviour? I would've thought it'd try
to do END if at all possible to clean up after itself.
Lessee, I think it's a kill 9 that can't be caught. And maybe kill 15,
but I've never played with that. Other signals can be caught, but I've
only done that in C, so my memory may be faded.
Re: Forking & Signals
Now if we take that same simple program and either
don't define $SIG{'TERM'} or set it to 'DEFAULT' we
get END when the parent dies, but when we kill the
child &cleanup isn't run (duh) but neither is END. Is
that standard behaviour?
The following is from perlfaq8 (perldoc perlfaq8):
The END block isn't called when untrapped signals kill the program,
though, so if you use END blocks you should also use
use sigtrap qw(die normal-signals);
Which I think is what you're after.
Neil
