Re: NSBeginAlertSheet not waiting for button to be pushed

On Feb 7, 2010, at 22:18, Chad Leigh -- ObjectWerks Inc wrote:

> 
> On Feb 7, 2010, at 12:58 PM, Kyle Sluder wrote:
> 
>> On Sun, Feb 7, 2010 at 11:16 AM, Chad Leigh -- ObjectWerks Inc
>> <chad+macosx-AU1NHruoRJaEK/[email protected]> wrote:
>>> I have read that.   As your quote said, "You can use the Application Kit's functional API for alert sheets."  It is not deprecated and fully supported at the moment.  Most of this app's code is from 2003 and this bit dates from that time.  I am just modifying a little where it gets called from with a new set of registration panels.
>> 
>> "It's not deprecated" is different from "there's a better way of doing
>> this which is preferred for new code." Since you are working with
>> existing code (a point which either did not come up or eluded me), it
>> makes a ton more sense to continue using NSBeginAlertSheet.
> 
> Sorry, I don't think I mentioned it in the beginning.
> 
> If there are resources in the future (ie enough people pay for a license to make it worth my while to do a lot of things I would like to do), it will get partially re-architected and I will probably be able to change the NSBeginAlertSheet use to a more modern (and generalized) approach as some things will have to change in the framework of the app itself.
> 
> The app is not perfect in design or anything.  It started out as a utility for my own use in 2003.  I have been using it live, daily, myself since 2005 though 90% of the existing code was written in 2003. I just had to get approval from the service provider it interfaces with to use it against their production servers which I finally got around to do in 2005 (the reason I did not push it earlier is that the reason I originally wrote it, Mac browsers not working with this service providers online web based interface, went away later in 2003 so my app was no longer a necessity to ditch Windows but a nice-to-have for efficiency and productivity). Somewhere along the way I got the idea other people might want to use it as well and have been wanting the last 5 or 6 years to make a public release.  But since late 2003 I have been busy with my business (non software, which I got into after the .com crash and no work for 6+ months)  and never took the time to polish it, fix bugs, etc.  Each year I have worked a week or three on it as the service provider changed things, or to start to add a licensing module, etc to it.  Now I am working to get it done and out the door.  If it does OK I will spend more time on it adding in new and better features, a new service provider, better reporting, etc.  But goal #1 is to get the existing app polished enough to release as a V1 very workable solution. 
> 
> I need to polish a few things, fix a few known bugs, finish the licensing and registration stuff, switch one or two features to use more robust Apple technologies, and add a couple really small but useful features (1-3 day features I call them).
> 
> So lots of things internally are not ideal, but it is very usable and I use it almost daily live since 2005.
> 
>> 
>>> Do you have any ideas on why it  may not be modal and wait for the OK button? What might be the cause of that?
>> 
>> Sheets don't run modally.
> 
> I should have put "modal" in "".  They do run modally to the UI they are attached to.
> 
>> That's their whole purpose as a functional
>> UI element; they only block the window they're attached to. This means
>> that NSBeginAlertSheet must be an asynchronous API; that's why you
>> pass it a delegate.
> 
> Which is not getting called :-( in this one case.  Every other similar use (which is not many) works.
> 
>> 
>>> Not in  this app.  Those panels cannot trigger the call that includes this particular alert sheet and the keyWindow call.  The utility function that is being called is in a non GUI library and makes a network call that can fail or return an error code from the remote server.  This utility class has no clue what the current window is.  However, it is only called by my apps windows, so to speak, and will never be called when some other window like a system panel is up.  It cannot be triggered that way.
>> 
>> If your utility class is acting asynchronously (I really hope so;
>> blocking the main thread waiting for network operations to complete
>> will cause beachballing and a horrible user experience),
> 
> Actually it does not (yet) work asynchronously.  I agree that is better and once I have the resources to do some re-architecting in order to fit some new features and a new service provider into it, that is one thing I will want to do (is on my > V1 to do list).  However, in the 5 years I have been using it, network latency and timeouts have not been an issue and most live requests finish in about 1-2 seconds and only once or twice since 2005 have I had network problems enough where it beachballs.  I agree though that the asynchronous way would be better and it will get there, eventually.  As I said above, it started out as a quick utility for my own use to solve my own internal problem so I was not worried about perfect user experience.
> 

Again, if that function does not have the window context, it should not use a sheet but a panel.

>> then you
>> cannot guarantee what window is key at the time you call
>> NSBeginAlertSheet. I could perform the action that triggers the
>> network operation, switch to a different window in your app, and then
>> some number of seconds later your network communications utility
>> object gets the timeout and displays the sheet.
> 
> Yes, agreed, except there are not other windows in the app at one time.  At least now.   

How do you know for sure? For instance, most apps automatically gets a "Special Characters" menu item that lets you open a utility window at any time. And don't say you don't have it, because that irrelevant. The point is that it CAN happen, and you CAN'T control it. It's a matter of principle.

>  The problem came in because I added a registration section before the app starts that has to use the same network operation to register with the service provider [one time registration, not each time the app runs]and there is no other way to send the correct window down the pipe so to speak.  Before I was referencing a window reference made for this very reason.
> 
>> 
>> The correct solution would be to communicate to the utility object
>> "Here is the window upon which you should display your sheet in the
>> event of an error."
> 
> It was actually working that way since there was a reference that I stuck the app window in as I mentioned above.  Now, there are also a panel used in the registration and preference panel, which is new, that has no way of letting itself be known.
> 
> I appreciate your comments.  Lots of things could be better done and hopefully I will have the resources to redo some of it as the app expands and I need to spend the time to do that.  And your comments help reinforce in my mind things that need to be part of the re-architecting.  
> 
> Now I am trying to understand why in this one case the NSBeginAlertSheet does not wait for the input but falls through the function call (and does not call the delegate selector either).

To answer that question you need to do some tests (yourselves, because we can't). Something is wrong in your case, and you clearly did not mention the relevant issue that causes this, therefore you need to figure that out and at least eliminate causes. We've pointed out lots of weaknesses in your design and code, so now it's YOUR responsibility to check whether those may be the cause. You still did not do that, you only gave excuses (and not good ones BTW). 

Christiaan

> 
> Anyway, I am re-architecting the application startup to a small degree and hopefully doing that will help make this work better...  I had kludged in my registration and initial preferences panel to the existing working app and am now trying to unkludge it today and make it work better.
> 
> 
>> Alternatively, since you seem to desire modal
>> operation, you could just use an alert panel instead of a sheet.
>> 
>>> I am explicitly choosing the window as best as the routine knows which is the keyWindow.
>> 
>> See above. I meant "explicitly choose a specific window."
>> 
>> --Kyle Sluder