MessageBox

QNX Newsgroups (Archives) qdn.public.qnxrtp.photon
1

I’m trying to use PtMessageBox(). The docs say:

This function displays the message specified by question, blocking
input to the specified parent widget until the message has been
acknowledged. If no parent is specified, blocking won’t occur,
but the message will persist until it’s acknowledged. If specified,
the parent widget must be a window.

But while the message is being displayed, input is NOT being blocked
to the parent. The parent I’m passing is a dialog (ABW_my_dialog).

Isn’t a dialog a qualifying parent?
Or am I missing something here?
(wouldn’t be the first time.)

Also, after calls to a CODE callback that successfully accomplished
whatever, and want to get rid of the dialog, what is the currect
thing to do?
a) return something other than continue?
b) PtUnrealizeWidget() the dialog?
c) PtDestroyWidget() the dialog?

This is a PhAB application.

2

Thank you for bringing this to our attention. It turns out that this
PtMessageBox() should block when given a parent and therefore I have
submitted a problem report to have this fixed for the future. As a work
around you can use the PtAlert() instead.
Your second question really depends on your requirements. If you don’t plan
on using that widget again then you could destroy the widget. On the other
hand if you do plan on using that widget again, you should probably just
unrealized it instead of recreating it for every use. Another option you
have is to visually hide the widget if time is a major issue. You could set
the Pt_ARG_POS to negative number off the viewable screen and use Pt_BLOCKED
in the Pt_ARG_FLAGS so the widget doesn’t get focus.

Thanks,
Dave B.



“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:b6d7gl$bo$1@inn.qnx.com…

I’m trying to use PtMessageBox(). The docs say:

This function displays the message specified by question, blocking
input to the specified parent widget until the message has been
acknowledged. If no parent is specified, blocking won’t occur,
but the message will persist until it’s acknowledged. If specified,
the parent widget must be a window.

But while the message is being displayed, input is NOT being blocked
to the parent. The parent I’m passing is a dialog (ABW_my_dialog).

Isn’t a dialog a qualifying parent?
Or am I missing something here?
(wouldn’t be the first time.)

Also, after calls to a CODE callback that successfully accomplished
whatever, and want to get rid of the dialog, what is the currect
thing to do?
a) return something other than continue?
b) PtUnrealizeWidget() the dialog?
c) PtDestroyWidget() the dialog?

This is a PhAB application.

3

Dave Boltz <dboltz@qnx.com> wrote:

Thank you for bringing this to our attention. It turns out that this
PtMessageBox() should block when given a parent and therefore I have
submitted a problem report to have this fixed for the future. As a work
around you can use the PtAlert() instead.

Glad to hear it.

Your second question really depends on your requirements. If you don’t plan
on using that widget again then you could destroy the widget. On the other
hand if you do plan on using that widget again, you should probably just
unrealized it instead of recreating it for every use. Another option you
have is to visually hide the widget if time is a major issue. You could set
the Pt_ARG_POS to negative number off the viewable screen and use Pt_BLOCKED
in the Pt_ARG_FLAGS so the widget doesn’t get focus.

I’ve gotten PtUnrealizWidget() to work.

This is a PhAB app and the dialog will be needed again. I seem to
recall that with Photon 1.14 PhAB was less graceful about if you
dismissed a dialog incorectly. I guess I was destroying it.

Does Photon 2 now have the ability to know if a PHAB widget is extant
and recreate it if it is not?

4

Dave Boltz <dboltz@qnx.com> wrote:

Unfortunately this is not managed for you. This means you will have to keep
track of this yourself mind you this shouldn’t be an issue as long as you
stay consistent in your code.

I understand.

My questin was more like:
In a PhAB app when a button click calls a Dialog callback is that dialog

  • realized
  • realted and realized
  • does it know which is necessary

So far, I’m guessing just realized. If this is true, then the answer
to how should I get rid of my dialog is to return it to the unrealized
state.

5

Unfortunately this is not managed for you. This means you will have to keep
track of this yourself mind you this shouldn’t be an issue as long as you
stay consistent in your code.

Regards,
Dave B.





“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:b6fc90$e7m$2@inn.qnx.com…

Dave Boltz <> dboltz@qnx.com> > wrote:
Thank you for bringing this to our attention. It turns out that this
PtMessageBox() should block when given a parent and therefore I have
submitted a problem report to have this fixed for the future. As a work
around you can use the PtAlert() instead.

Glad to hear it.

Your second question really depends on your requirements. If you don’t
plan
on using that widget again then you could destroy the widget. On the
other
hand if you do plan on using that widget again, you should probably just
unrealized it instead of recreating it for every use. Another option
you
have is to visually hide the widget if time is a major issue. You could
set
the Pt_ARG_POS to negative number off the viewable screen and use
Pt_BLOCKED
in the Pt_ARG_FLAGS so the widget doesn’t get focus.

I’ve gotten PtUnrealizWidget() to work.

This is a PhAB app and the dialog will be needed again. I seem to
recall that with Photon 1.14 PhAB was less graceful about if you
dismissed a dialog incorectly. I guess I was destroying it.

Does Photon 2 now have the ability to know if a PHAB widget is extant
and recreate it if it is not?

6

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:<b6fh7t$l86$1@inn.qnx.com>…

Dave Boltz <> dboltz@qnx.com> > wrote:
Unfortunately this is not managed for you. This means you will have to
keep
track of this yourself mind you this shouldn’t be an issue as long as
you
stay consistent in your code.

I understand.

My questin was more like:
In a PhAB app when a button click calls a Dialog callback is that dialog

  • realized
  • realted and realized
  • does it know which is necessary

What do you mean by ‘realted’?

When you create a dialog in this fashion you are in effect using the
ApCreateModule(). This function will return the pointer to the existing
module if it is already instantiated and make that module active.

So far, I’m guessing just realized. If this is true, then the answer
to how should I get rid of my dialog is to return it to the unrealized
state.

Since you are instantiating the dialog using the PhAB convenience then you
would probably be best to use the one of the ‘code types’ of ‘Done’ or
‘Cancel’ as well. This way you won’t have to worry about handling this
yourself.

Regards,
Dave B.

7

Bill Caroselli <qtps@earthlink.net> wrote:

I’ve gotten PtUnrealizWidget() to work.

There’s a big difference between unrealizing a widget and destroying it.
If you just unrealize a dialog, it remembers any changes to its state
that user input or your code may have caused. When you realize it
again, it’ll come up at the same position and size and with the same
contents it had when you unrealized it.

When you destroy a widget (or, more accurately, soon after), it ceases
to exist; if you want to preserve any information that was stored in the
widget, you have to grab it from the widget before it’s destroyed. If
you then create a new copy of it, it’ll come up in its default state,
and you’ll need to put the contents in the widgets again.

Normally, when I want to get rid of a dialog after it’s done its job, I
destroy it. Unrealizing can produce unexpected results – imagine, for
instance, that the user has moved the main window to a different virtual
console but the dialog remembers its position on the old console…

This is a PhAB app and the dialog will be needed again. I seem to
recall that with Photon 1.14 PhAB was less graceful about if you
dismissed a dialog incorectly. I guess I was destroying it.

I remember there were changes in this area before Photon 1.14, but
from a quick look at the code, QNX6 should behave the same way as Photon
1.14.

Does Photon 2 now have the ability to know if a PHAB widget is extant
and recreate it if it is not?

Both Photon 1.14 and 2 keep track of whether a dialog module exists or
not by setting its ABW variable to NULL when it’s destroyed. For any
other PhAB widget (including the contents of a dialog module), the ABW
variable is set when the widget is created, every time it’s created, and
never set to NULL, even if the widget is destroyed.

When your code calls ApCreateModule() on a dialog, or when a widget
invokes a PhAB callback that points to a dialog module, the PhAB
library checks if the dialog already exists (by examining its ABW
variable). If it doesn’t, it gets created (and its setup function, if
any, is called).

If the dialog already exists, the library just makes sure that it’s
realized, and brings it to the front. (Before 1.14, it used to do
something else if the dialog existed but was unrealized; I don’t
remember what exactly, but I remember that it was something unexpected
to me…)

8

Dave Boltz <dboltz@qnx.com> wrote:

“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:<b6fh7t$l86$> 1@inn.qnx.com> >…
Dave Boltz <> dboltz@qnx.com> > wrote:
Unfortunately this is not managed for you. This means you will have to
keep
track of this yourself mind you this shouldn’t be an issue as long as
you
stay consistent in your code.

I understand.

My questin was more like:
In a PhAB app when a button click calls a Dialog callback is that dialog

  • realized
  • realted and realized
  • does it know which is necessary

What do you mean by ‘realted’?
Sorry, bad typo. That should have been “created”.



When you create a dialog in this fashion you are in effect using the
ApCreateModule(). This function will return the pointer to the existing
module if it is already instantiated and make that module active.


So far, I’m guessing just realized. If this is true, then the answer
to how should I get rid of my dialog is to return it to the unrealized
state.

Since you are instantiating the dialog using the PhAB convenience then you
would probably be best to use the one of the ‘code types’ of ‘Done’ or
‘Cancel’ as well. This way you won’t have to worry about handling this
yourself.

Yes, but I do want to execute some of my own code when "Done"ing or
"Cancel"ing. So it all boils down to do DONE and CANCEL to an
unrealize or a destroy?

I’m sorry this is taking so long. It really doesn’t seem like it
should be such a complicated thing. But (HELLO STEVE) the docs don’t
address what the correct way to get rid of a dialog from code is.

9

Wojtek Lerch <wojtek_l@yahoo.ca> wrote:

[lots of good stuff removed]

Thank you Wojtek. This is very helpful.

I do think it should be move obvious in the docs however. Perhaps in
the “Working with Code” section. That is where I usually go for this
kind of info.

10

Bill Caroselli <qtps@earthlink.net> wrote:
: I’m sorry this is taking so long. It really doesn’t seem like it
: should be such a complicated thing. But (HELLO STEVE) the docs don’t
: address what the correct way to get rid of a dialog from code is.

I’ll make sure that the writer who works on the Photon docs (I’m not the
one anymore) sees this thread.

Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

11

Bill Caroselli <qtps@earthlink.net> wrote:

Yes, but I do want to execute some of my own code when "Done"ing or
"Cancel"ing. So it all boils down to do DONE and CANCEL to an
unrealize or a destroy?

Both. :slight_smile:

In other words, they destroy; the unrealizing is just the first part of
the destruction.

BTW You can attach your own code to a Done or Cancel callback. The
dialog will be destroyed after your function returns.

What’s more, it’ll only be destroyed if your function returns
Pt_CONTINUE. You can return Pt_END to keep the dialog. (This little
detail seems either undocumented or hard to find in the docs… Hello
docs people, are you listening?..)

12

Wojtek Lerch <wojtek_l@yahoo.ca> wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote:
Yes, but I do want to execute some of my own code when "Done"ing or
"Cancel"ing. So it all boils down to do DONE and CANCEL to an
unrealize or a destroy?

Both. > :slight_smile:

In other words, they destroy; the unrealizing is just the first part of
the destruction.

BTW You can attach your own code to a Done or Cancel callback. The
dialog will be destroyed after your function returns.

What’s more, it’ll only be destroyed if your function returns
Pt_CONTINUE. You can return Pt_END to keep the dialog. (This little
detail seems either undocumented or hard to find in the docs… Hello
docs people, are you listening?..)

Thank you Wojtek. This is very helpful.

I know that most stuff is in the docs. It just usually isn’t where
I expect to find it. Will there ever be a “Notes” section to the
helpviewer? It would eb very helpful if I could make on-line notes to
myself. This was discussed way back in the QNX4 days. If the code to
helpviewer is available I’d be happy to add it and give it back to
QSSL.

13

Dave Boltz <dboltz@qnx.com> wrote:

Thank you for bringing this to our attention. It turns out that this
PtMessageBox() should block when given a parent and therefore I have
submitted a problem report to have this fixed for the future. As a work
around you can use the PtAlert() instead.
Your second question really depends on your requirements. If you don’t plan
on using that widget again then you could destroy the widget. On the other
hand if you do plan on using that widget again, you should probably just
unrealized it instead of recreating it for every use. Another option you
have is to visually hide the widget if time is a major issue. You could set
the Pt_ARG_POS to negative number off the viewable screen and use Pt_BLOCKED
in the Pt_ARG_FLAGS so the widget doesn’t get focus.

Thanks,
Dave B.

Anothr PtMessageBox() buglet (I think).

After a message box is displayed the “OK” button is underlined implying
that hitting on the keyboard should dismis the message box.
It does not. Should it?

14

I tried a simple test here and it seems to work. Could you send me a small
reproducible test case along with the output from ‘uname -a’ please?

Thanks,
Dave B.


“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:b6sli0$gid$1@inn.qnx.com…

Dave Boltz <> dboltz@qnx.com> > wrote:
Thank you for bringing this to our attention. It turns out that this
PtMessageBox() should block when given a parent and therefore I have
submitted a problem report to have this fixed for the future. As a work
around you can use the PtAlert() instead.
Your second question really depends on your requirements. If you don’t
plan
on using that widget again then you could destroy the widget. On the
other
hand if you do plan on using that widget again, you should probably just
unrealized it instead of recreating it for every use. Another option
you
have is to visually hide the widget if time is a major issue. You could
set
the Pt_ARG_POS to negative number off the viewable screen and use
Pt_BLOCKED
in the Pt_ARG_FLAGS so the widget doesn’t get focus.

Thanks,
Dave B.

Anothr PtMessageBox() buglet (I think).

After a message box is displayed the “OK” button is underlined implying
that hitting on the keyboard should dismis the message box.
It does not. Should it?