Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

Mac OS-X Dialogs

Posted on 2004-10-21
25
Medium Priority
?
523 Views
Last Modified: 2013-12-26
I've written a MAC OS-X daemon and it works great, however I have one error case where I need to present the user with an "OK" dialog box similar to ShowMessage('BLAH') in delphi for windows...
The message at most would be 2 lines, and an OK button to close the message. Nothing more. I am new to mac and I can't believe I can't find how to do this on google... It is a console app.

-D
0
Comment
Question by:DABOMB
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 13
  • 7
  • 5
25 Comments
 
LVL 23

Expert Comment

by:brettmjohnson
ID: 12373551
By definition, a daemon runs in the background, disconnected from the terminal.
Most importantly, if the daemon is in the "background", and some user is logged in,
then some other application is in "foreground" - has the focus of the GUI.  If an
unrelated program throws a dialog box up over the foreground app, it is not only
considered "bad manners", but could seriously confuse the user.  It is very much
against the Macintosh Human Interface Guidelines, and typical of the worst-behaved
Windows apps.

0
 
LVL 23

Expert Comment

by:brettmjohnson
ID: 12373627
Daemons typically log errors to system log files, usually /var/log/system.log
Consider the logger command, or the syslog library routines:

man  logger
man  syslog

0
 
LVL 3

Author Comment

by:DABOMB
ID: 12373800
Ok, let me clarify... This "Daemon" is monitoring an external device for an event and launching an app when the event is received. (Ex: pressing an extra button on a keyboard) However, should the program not exist, I want it to prompt the user to either re-install the program or contact tech support. Since the user-interaction is necessary I dont think it would be "bad manners" in this situation.

-D
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 23

Expert Comment

by:brettmjohnson
ID: 12374641
Since a daemon has no foreground UI access, I suggest the following:

Since the result of the event is to launch an application, I suggest you
have a default, tiny application that you launch in the event that third-
party application is not available.

0
 
LVL 3

Author Comment

by:DABOMB
ID: 12374737
Ok, but that brings me back do dialogs, this tiny app would need to have a dialog, and this is beyond my skill set on mac.
Is there any way to just add a certain header file and a command that would pop up the dialog?

-D
0
 
LVL 44

Assisted Solution

by:Karl Heinz Kremer
Karl Heinz Kremer earned 600 total points
ID: 12375169
You could use a small AppleScript program to display your dialog box:

display dialog "This is the string to be displayed" buttons {"OK"}
0
 
LVL 3

Author Comment

by:DABOMB
ID: 12375418
khkremer,

How reliable would that be across the whole spectrum of 10.1.x to 10.3.5?

Would I just make the script and launch it using osascript? how reliable is this as well?

Thanks,
-D
0
 
LVL 23

Assisted Solution

by:brettmjohnson
brettmjohnson earned 600 total points
ID: 12375434
For such a simple task, I would create a 10 line applescript that
I would launch from your daemon using system()

system("/path/to/myScript.scpt");

myScript.scpt would look like this:
exec osascript <<\EOF
tell application "Finder"
        display dialog "My application was not found" buttons {"OK"} default button 1
end tell


http://developer.apple.com/documentation/AppleScript/Reference/StudioReference/sr10_panel_suite/chapter_10_section_15.html
http://www.macosxhints.com/article.php?story=20040617170055379
http://www.hoboes.com/html/NetLife/AppleScript/AppleScriptandtheCommandLine.html

0
 
LVL 3

Author Comment

by:DABOMB
ID: 12375500
We are getting so close, just so you know I'm going to increase the points and do a split since you both came up with the ideas so close to one another.

Brett,

I tried your script and it worked, but with one flaw. It does not focus the dialog, it keeps it in the bottom and bounces the Finder window, is there a way around this?

-D
0
 
LVL 3

Author Comment

by:DABOMB
ID: 12375506
Oh and the script does not close untill you press ok. (this might cause my service to hang?)
0
 
LVL 3

Author Comment

by:DABOMB
ID: 12375665
NVM, just needed an activate statement. If I compile this script on 10.3.5 will it work on 10.1.x?

-D
0
 
LVL 44

Accepted Solution

by:
Karl Heinz Kremer earned 600 total points
ID: 12375677
brettmjohnson already implied this, but you don't need osascript: Just compile the script and save it as "Application" (In the Script Editor select "Save As" and then select "Application" from the list). This will create an application that can be executed directly.

The Mac is not Windows :-) This is the reason why the application is launched in the background, and not "in your face" as Windows would do it. The user can decide when to stop the current task to pay attention to a program that want's attention.

If you want your "daemon" to continue, you need to fork a new process, and then start the message box from the new process ID, while the old process will continue with whatever it's doing.
0
 
LVL 23

Expert Comment

by:brettmjohnson
ID: 12375683
> I tried your script and it worked, but with one flaw. It does not focus the dialog, it keeps it in the
> bottom and bounces the Finder window, is there a way around this?

Add the command "activate" to the script to tell Finder to orderFront:
exec osascript <<\EOF
tell application "Finder"
        activate
        display dialog "My application was not found" buttons {"OK"} default button 1
end tell



> Oh and the script does not close untill you press ok. (this might cause my service to hang?)

Now you are just being lazy.  Consider using popen(), fork()+exec(), & (run script in background),
or "giving up after" parameter to the "display dialog" command.
0
 
LVL 3

Author Comment

by:DABOMB
ID: 12375760
lol you caught me on the laziness, been a loooong day, anyway.

khkremer: "The Mac is not Windows :-) This is the reason why the application is launched in the background, and not "in your face" as Windows would do it."

I would assume the user would not care since what they want to do is open the app using my button connected to the daemon. They'd be expecting the app to open, if the app doesnt open the error message should. :)

Thank you both very much.

-D
0
 
LVL 44

Expert Comment

by:Karl Heinz Kremer
ID: 12375803
Thanks for reminding me of "activate". I never use this, mainly because it's so annoying to have to deal with this on Windows on a regular basis (I have to use Lotus Notes on Windows for email - IT's decision - and every time I receive email, a dialog window pops up, grabs focus, and needs to be dismissed... AAARRRRGGGGGHHHHH :-)
0
 
LVL 23

Expert Comment

by:brettmjohnson
ID: 12377844
I, too, hate when a background app throws a dialog and grabs focus while I'm working.
I consider it extremely bad behaviour.  I already admonished DABOMB on this design
decision, but he seems determined to go forward with it.  He will be roundly criticized
by his users and may eventually change to a less user-antagonistic design.

Windows users are accustomed to an annoying user experience, whereas Mac users are
quite intolerant of bad program behaviour.  Windows programmers fail to realize that
porting apps to the Mac doesn't just mean learning a different set of system APIs, it
means refactoring the design to be user-centric and follow the Apple Human Interface
Guidelines.

Earlier versions of Mail.app would throw a dialog and grab focus for POP3 connection
failures.  Apple hadn't noticed because they used IMAP in-house.  I brought it to their
attention, suggested better ways to handle flakey connections, and the next release
of Mail.app had nearly all my suggestions implemented.  I was impressed.


0
 
LVL 3

Author Comment

by:DABOMB
ID: 12382457
Ok, this might be beating a dead horse... But you are telling me that you as a user, who is using my product, and presses the button which you expect to bring up an app on the screen, would not want to see the failure notice come forward, even though if the launch was successful the app itself would pop up front considering that you pressed the button this would be your current task?

-D
0
 
LVL 3

Author Comment

by:DABOMB
ID: 12382504
I wish I could select both as the answer but here is what I ended up doing with my script.

simlply 2 lines:

activate
display dialog "yada yada...

Saved as app you dont have to tell finder to do the dialog if it is it's own app. You may be right on the popup, when I run through some product eval testing with a group of mac people we will find out if it bugs them :)

Thank you both for your help, I would have never found this at all as I didnt even realize applscript still existed in OS X, I did alot of it in 9 and pretty much forgot all the syntax anyway.
0
 
LVL 44

Expert Comment

by:Karl Heinz Kremer
ID: 12382661
Thanks. The points from this question put me over the one million mark :-)
0
 
LVL 3

Author Comment

by:DABOMB
ID: 12382783
ackkkkk..... and i'm downhere at 14000 after 5 years... lol guess i'm not very active
0
 
LVL 3

Author Comment

by:DABOMB
ID: 12415280
Very strange behavior... If I move the script away from the directory I saved it in. It doesnt work anymore...

-D
0
 
LVL 44

Expert Comment

by:Karl Heinz Kremer
ID: 12415574
Are you using the "exec osascript" method to run the script, or did you compile the script?
0
 
LVL 3

Author Comment

by:DABOMB
ID: 12416119
compiled
0
 
LVL 3

Author Comment

by:DABOMB
ID: 12416233
now the osascript method isnt working what have i done?!\ ack, oh well.
0
 
LVL 23

Expert Comment

by:brettmjohnson
ID: 12418317
Make sure the file has execute permissions for the current user.

0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This is to be the first in a series of articles demonstrating the development of a complete windows based application using the MFC classes.  I’ll try to keep each article focused on one (or a couple) of the tasks that one may meet.   Introductio…
Introduction: Load and Save to file, Document-View interaction inside the SDI. Continuing from the second article about sudoku.   Open the project in visual studio. From the class view select CSudokuDoc and double click to open the header …
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
This tutorial will teach you the special effect of super speed similar to the fictional character Wally West aka "The Flash" After Shake : http://www.videocopilot.net/presets/after_shake/ All lightning effects with instructions : http://www.mediaf…
Suggested Courses

618 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question