Implement a BeOS native dialog for pref_Alert

RESOLVED FIXED

Status

()

RESOLVED FIXED
16 years ago
15 years ago

People

(Reporter: timeless, Assigned: beos)

Tracking

Trunk
x86
BeOS
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
While rewriting prefapi.cpp I noticed that BeOS doesn't haev a useful
implementation.
(Assignee)

Comment 1

16 years ago
Timeless, what is pref alert?  (Class, method, ...) and where?
Status: NEW → ASSIGNED
(Assignee)

Comment 2

16 years ago
Created attachment 109912 [details] [diff] [review]
pref_Alert impl for BeOS
(Reporter)

Comment 3

16 years ago
Comment on attachment 109912 [details] [diff] [review]
pref_Alert impl for BeOS

>       // Calling Go(NULL) runs the BAlert object asynchronously.  Go will also delete the BAlert when finished

Go() is blocking (which is indeed what you want), so the comment is wrong, how
about this:
       // Calling Go(NULL) runs the BAlert and waits for the user to close the
window.  Go will delete the BAlert when it finishes.

InterfaceKit/Alert.html#Go()
   Go() doesn't return until the user operates a button to dismiss the panel.
When it returns, the window will have been closed, the window thread will have
been killed, and the BAlert object will have been deleted.
Attachment #109912 - Flags: review+
(Assignee)

Comment 4

16 years ago
Go() with no argument is synchronous, and therefor blocking, correct.  Go(NULL)
is asynchronous.  The snippet you gave from the BeBook is for the syncronous
method.   Read a little further down, for Go(NULL):

The BInvoker argument version is asynchronous: The function returns immediately
(with B_OK) and the button index is delivered as the int32 "which" field of the
BMessage that's sent to the BInvoker's target.  If you call Go() with a
(literal) NULL argument...  alert->Go(NULL); ... the asynchronous version is
used, but the BMessage isn't sent.


 Though the BAlert is modal in both cases, execution of the thread is allowed to
continue with the later.  (I tested this on the HelloWorld sample app)
(Reporter)

Comment 5

16 years ago
how confusing. well, the other impls are blocking, i'm pretty sure that's
intended. So use my comment and use Go() :).

this dialog tends to be fatal (although it probably should throw you back to the
profilemanager), but wether it's fatal or sends you back to the profile manager,
you don't want either of those things happening while the user sees this dialog.
(Assignee)

Comment 6

15 years ago
Created attachment 126269 [details] [diff] [review]
updated patch as per comments/discussion w/ timeless

Updated patch to make the alert syncronous, and therefore blocking
Attachment #109912 - Attachment is obsolete: true
(Assignee)

Comment 7

15 years ago
Comment on attachment 126269 [details] [diff] [review]
updated patch as per comments/discussion w/ timeless

need r and sr
Attachment #126269 - Flags: superreview?(alecf)
Attachment #126269 - Flags: review?(timeless)
(Reporter)

Updated

15 years ago
Attachment #126269 - Flags: review?(timeless) → review+

Comment 8

15 years ago
Comment on attachment 126269 [details] [diff] [review]
updated patch as per comments/discussion w/ timeless

ugh, this is lame... we should stop using platform-specific messages :(
sr=alecf but I'd really like someone to improve on this...

(another way to approach this would be to write to the console service)
Attachment #126269 - Flags: superreview?(alecf) → superreview+
(Assignee)

Comment 9

15 years ago
checked in, marking fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.