Re: GetMonitorFromWindow
Re: GetMonitorFromWindow
- Subject: Re: GetMonitorFromWindow
- From: John Stiles <email@hidden>
- Date: Fri, 07 Mar 2008 09:33:36 -0800
Well all right then, the OP should check out the NSWindow delegate
methods, and NSScreen. :)
Randall Meadows wrote:
On Mar 7, 2008, at 9:38 AM, John Stiles wrote:
I'm going to jump on the bandwagon and say that your client is wrong.
Mac apps do not and should not do this.
Sorry, I've got to jump in here as well, as much as I've tried to keep
my mouth shut.
Apparao Mulpuri posted a question requesting help. He posted only the
relevant details of his problem, not the entire backstory of the
problem or the requirements (or lack thereof) leading to the problem.
Immediately, people posted--people who knew the solution to the
problem--NOT the solution, but rather rants second-guessing the OP.
It took additional posts in order to coax out the correct solution,
one that fit his (unstated) requirements. Are we now going to have to
start detailing project and client requirements when we ask for help,
in order to actually get that help, and drag the signal:noise ratio of
this list down to abysmal depths?
And (not to pick on John or anyone in particular, but just making a
general statement), how 'bout in the future, if you know the solution,
actually post it, and then (gently!) suggest that perhaps this isn't
the best way to handle the situation and that perhaps a rethinking of
the design might be in order (or even suggest an alternate solution).
That way, you've been helpful, and you've pointed out--to perhaps a
programmer new to the high-standards Macintosh world--that that's not
the standard way we do things.
And then, let the OP decide whether to make us happy, or keep his
employer/client happy. Personally, I know who I'd choose to keep
happy (no offense to you fine folks here, but you don't put food on my
family's table and pay to keep my house warm).
Yes, there standards that, when deviated from, can potentially ruin a
product's chances of success.
And yes, there are very legitimate reasons for deviating from Mac UI
and UE standards. I'm wagering that consistency of cross-platform
in-house applications is probably the driving force in this case; less
confusion when employees move from one platform to another, and only 1
manual and help desk script to maintain.
And I say all this from the perspective of one who's had to do
something very similar to the original question: making sure that a
window remained solely on one screen (back in the OS 9 days). My
client had monitors that weren't the same resolution, and a window
crossing the boundaries looked stupid. This was a *huge* client for
my company at the time, and to tell them they were wrong and we
weren't going to meet their requirements would, shall we say, not have
been a good move for either myself nor my company, to put it mildly.
Sorry this turned into such a harsh sounding rant; that certainly
wasn't my intention, but I've been on the receiving end of what I
talked about, as well as being guilty of being on the other end as
well. I just feel it's easier (for all involved) to answer the
question asked, if there is an answer, rather than start out in a
confrontational manner.
randy <- descending from the soap box
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden