Re: [Iup-users] SIMULATEMODAL
I see the problem: I was using IupShow instead of
IupPopup(ih,IUP_CURRENT,IUP_CURRENT).
On 2/16/2022 at 4:49 PM, Andrew Robinson wrote:
You know, you could give me some code that works like I asked for. Anyways,
will this work for you?:
int main() {
iHandle hMat1=0,hMat2=0 ;
void *pBox6,*pBox1,*pBtn1,*pMainDlg,*pMainCfg,*pDlg1 ;
// Custom Dialog
hMat2=IupMatrixEx(NULL);
IupSetAttribute(hMat2,"NUMLIN","2");
IupSetAttribute(hMat2,"NUMCOL","2");
IupSetAttribute(hMat2,"NUMCOL_VISIBLE","2");
IupSetAttribute(hMat2,"NUMLIN_VISIBLE","2");
IupSetAttribute(hMat2,"EXPAND","NO");
*pBox6=IupVbox(hMat2,NULL);
IupSetAttribute(pBox6,"MARGIN","5x5");
pDlg1=IupDialog(pBox6);
IupSetAttribute(pDlg1,"TITLE","Test");
IupSetAttribute(pDlg1,"RESIZE","NO");
IupSetAttribute(pDlg1,"MAXBOX","NO");
IupSetAttribute(pDlg1,"MINBOX","NO");
IupSetCallback(pDlg1,"CLOSE_CB",addr cbDlg1Close);
// Main Dialog
hMat1=IupMatrixEx(NULL);
IupSetAttribute(hMat1,"NUMLIN","2");
IupSetAttribute(hMat1,"NUMCOL","2");
IupSetAttribute(hMat1,"NUMCOL_VISIBLE","2");
IupSetAttribute(hMat1,"NUMLIN_VISIBLE","2");
IupSetAttribute(hMat1,"HLCOLOR","0 0 255"); // This doesn't work
IupSetAttribute(hMat1,"HLCOLORALPHA","255"); // This doesn't work
pBtn1=IupButton(NULL,NULL);
IupSetAttribute(pBtn1,"SIZE","45x");
IupSetAttribute(pBtn1,"TITLE","SHOW :");
IupSetCallback(pBtn1,"ACTION",addr cbBtnShow);
pBox1=IupVbox(hMat1,pBtn1,NULL);
pMainDlg=IupDialog();
pMainCfg=IupConfig();
IupSetAttribute(pMainCfg,"APP_FILENAME","./PolymerDB.cfg");
IupConfigLoad(pMainCfg);
IupSetAttributeHandle(NULL,"PARENTDIALOG",pMainDlg);
IupSetAttribute(pMainDlg,"CONFIG",pMainCfg);
IupConfigDialogShow(pMainCfg,pMainDlg,"PolymerDB");
IupSetAttribute(pMainDlg,"TITLE","Polymer Database");
IupMainLoop();
IupDestroy(pMainDlg);
return(EXIT_SUCCESS); }
void cbBtnShow() {
IupConfigDialogShow(pMainCfg,pDlg1,"DatList");
IupShow(pDlg1);
IupSetAttribute(pMainDlg,"ACTIVE","NO");
return(); }
void cbDlg1Close() {
IupConfigDialogClosed(pMainCfg,pDlg1,"DatList");
return(); }
You can leave off all the config stuff and it will still perform the same, but
I left it in anyways in case of some other issue I'm not aware of exists when
doing these kind of things.
Thanks,
Andrew
On 2/16/2022 at 3:12 PM, Antonio Scuri wrote:
Almost all predefined dialogs are simply IupDialog, except the native ones,
like IupFileDlg. Three is no extra management when a predefined dialogs is
shown.
Maybe you can build a simple sample code to reproduce your problem? And we
start from that.
Em qua., 16 de fev. de 2022 18:52, Andrew Robinson
escreveu:
"You replied only to me"
Sorry. Will try to not let that happen again.
"When a dialog is closed the system brings the parent or another child to
foreground and it sets the focus. IUP actually doesn't interfere in the system
behavior."
This isn't about system behavior, this is about following proper programming
procedures. The Win10 documentation says you must call EndDialog to end a
modal dialog and apparently IUP does not do that for Windows and that is a
problem for IUP using custom dialogs.
"I tested here using the tools executable, like IupView or IupVisualLED, when
a child dialog is closed the main dialog gets its focus back."
The predefined dialogs will do that but a custom dialog will not. What do the
predefined dialogs do that the custom dialog does not (or is not documented to
do)?
Thanks,
Andrew
On 2/16/2022 at 12:51 PM, Antonio Scuri wrote:
Obs: You replied only to me, so I'm including the list in the reply again.
> You say "I guess" but is that how it is actually done in for all the
predefined dialogs in IUP?
> Why interrupt that default sequence of events just so you can add a very
necessary IupSetFocus that you can never leave out or it will never work? That
default behavior doesn't make sense, it is not documented to function like
that, and the default behavior actually doesn't work.
There is no default behavior set by IUP. When a dialog is closed the system
brings the parent or another child to foreground and it sets the focus. IUP
actually doesn't interfere in the system behavior.
I tested here using the tools executable, like IupView or IupVisualLED, when a
child dialog is closed the main dialog gets its focus back.
Best,
Scuri
Em qua., 16 de fev. de 2022 às 16:15, Andrew Robinson
escreveu:
To any other programmers out there that are experiencing this same issue, here
is my workaround (psuedocode):
setAttribute pDlg1 "CLOSE_CB=Dlg1_Close_cb"
myButton_cb {
IupShow pDlg1
pMainDlg ACTIVE='NO' }
Dlg1_Close_cb {
pMainDlg ACTIVE='YES' }
Do not use SIMULATEMODAL='YES'. The advantage of this workaround is that you
can (I mean must) selectively make any other custom dialogs an exception to
the rule, if need be.
Thanks,
Andrew
On 2/16/2022 at 11:55 AM, Andrew Robinson wrote:
Neither IupSetFocus not
Re: [Iup-users] SIMULATEMODAL
You know, you could give me some code that works like I asked for. Anyways,
will this work for you?:
int main() {
iHandle hMat1=0,hMat2=0 ;
void *pBox6,*pBox1,*pBtn1,*pMainDlg,*pMainCfg,*pDlg1 ;
// Custom Dialog
hMat2=IupMatrixEx(NULL);
IupSetAttribute(hMat2,"NUMLIN","2");
IupSetAttribute(hMat2,"NUMCOL","2");
IupSetAttribute(hMat2,"NUMCOL_VISIBLE","2");
IupSetAttribute(hMat2,"NUMLIN_VISIBLE","2");
IupSetAttribute(hMat2,"EXPAND","NO");
*pBox6=IupVbox(hMat2,NULL);
IupSetAttribute(pBox6,"MARGIN","5x5");
pDlg1=IupDialog(pBox6);
IupSetAttribute(pDlg1,"TITLE","Test");
IupSetAttribute(pDlg1,"RESIZE","NO");
IupSetAttribute(pDlg1,"MAXBOX","NO");
IupSetAttribute(pDlg1,"MINBOX","NO");
IupSetCallback(pDlg1,"CLOSE_CB",addr cbDlg1Close);
// Main Dialog
hMat1=IupMatrixEx(NULL);
IupSetAttribute(hMat1,"NUMLIN","2");
IupSetAttribute(hMat1,"NUMCOL","2");
IupSetAttribute(hMat1,"NUMCOL_VISIBLE","2");
IupSetAttribute(hMat1,"NUMLIN_VISIBLE","2");
IupSetAttribute(hMat1,"HLCOLOR","0 0 255"); // This doesn't work
IupSetAttribute(hMat1,"HLCOLORALPHA","255"); // This doesn't work
pBtn1=IupButton(NULL,NULL);
IupSetAttribute(pBtn1,"SIZE","45x");
IupSetAttribute(pBtn1,"TITLE","SHOW :");
IupSetCallback(pBtn1,"ACTION",addr cbBtnShow);
pBox1=IupVbox(hMat1,pBtn1,NULL);
pMainDlg=IupDialog();
pMainCfg=IupConfig();
IupSetAttribute(pMainCfg,"APP_FILENAME","./PolymerDB.cfg");
IupConfigLoad(pMainCfg);
IupSetAttributeHandle(NULL,"PARENTDIALOG",pMainDlg);
IupSetAttribute(pMainDlg,"CONFIG",pMainCfg);
IupConfigDialogShow(pMainCfg,pMainDlg,"PolymerDB");
IupSetAttribute(pMainDlg,"TITLE","Polymer Database");
IupMainLoop();
IupDestroy(pMainDlg);
return(EXIT_SUCCESS); }
void cbBtnShow() {
IupConfigDialogShow(pMainCfg,pDlg1,"DatList");
IupShow(pDlg1);
IupSetAttribute(pMainDlg,"ACTIVE","NO");
return(); }
void cbDlg1Close() {
IupConfigDialogClosed(pMainCfg,pDlg1,"DatList");
return(); }
You can leave off all the config stuff and it will still perform the same, but
I left it in anyways in case of some other issue I'm not aware of exists when
doing these kind of things.
Thanks,
Andrew
On 2/16/2022 at 3:12 PM, Antonio Scuri wrote:
Almost all predefined dialogs are simply IupDialog, except the native ones,
like IupFileDlg. Three is no extra management when a predefined dialogs is
shown.
Maybe you can build a simple sample code to reproduce your problem? And we
start from that.
Em qua., 16 de fev. de 2022 18:52, Andrew Robinson
escreveu:
"You replied only to me"
Sorry. Will try to not let that happen again.
"When a dialog is closed the system brings the parent or another child to
foreground and it sets the focus. IUP actually doesn't interfere in the system
behavior."
This isn't about system behavior, this is about following proper programming
procedures. The Win10 documentation says you must call EndDialog to end a
modal dialog and apparently IUP does not do that for Windows and that is a
problem for IUP using custom dialogs.
"I tested here using the tools executable, like IupView or IupVisualLED, when
a child dialog is closed the main dialog gets its focus back."
The predefined dialogs will do that but a custom dialog will not. What do the
predefined dialogs do that the custom dialog does not (or is not documented to
do)?
Thanks,
Andrew
On 2/16/2022 at 12:51 PM, Antonio Scuri wrote:
Obs: You replied only to me, so I'm including the list in the reply again.
> You say "I guess" but is that how it is actually done in for all the
predefined dialogs in IUP?
> Why interrupt that default sequence of events just so you can add a very
necessary IupSetFocus that you can never leave out or it will never work? That
default behavior doesn't make sense, it is not documented to function like
that, and the default behavior actually doesn't work.
There is no default behavior set by IUP. When a dialog is closed the system
brings the parent or another child to foreground and it sets the focus. IUP
actually doesn't interfere in the system behavior.
I tested here using the tools executable, like IupView or IupVisualLED, when a
child dialog is closed the main dialog gets its focus back.
Best,
Scuri
Em qua., 16 de fev. de 2022 às 16:15, Andrew Robinson
escreveu:
To any other programmers out there that are experiencing this same issue, here
is my workaround (psuedocode):
setAttribute pDlg1 "CLOSE_CB=Dlg1_Close_cb"
myButton_cb {
IupShow pDlg1
pMainDlg ACTIVE='NO' }
Dlg1_Close_cb {
pMainDlg ACTIVE='YES' }
Do not use SIMULATEMODAL='YES'. The advantage of this workaround is that you
can (I mean must) selectively make any other custom dialogs an exception to
the rule, if need be.
Thanks,
Andrew
On 2/16/2022 at 11:55 AM, Andrew Robinson wrote:
Neither IupSetFocus not IupGetFocus works to resolve this issue. Do you have
any simple working code and app of how this is done?
NOTE: The examples IUP give
Re: [Iup-users] SIMULATEMODAL
Almost all predefined dialogs are simply IupDialog, except the native ones,
like IupFileDlg. Three is no extra management when a predefined dialogs is
shown.
Maybe you can build a simple sample code to reproduce your problem? And we
start from that.
Em qua., 16 de fev. de 2022 18:52, Andrew Robinson
escreveu:
> "You replied only to me"
>
> Sorry. Will try to not let that happen again.
>
> "When a dialog is closed the system brings the parent or another child to
> foreground and it sets the focus. IUP actually doesn't interfere in the
> system behavior."
>
> This isn't about system behavior, this is about following proper
> programming procedures. The Win10 documentation says you must call
> EndDialog to end a modal dialog and apparently IUP does not do that for
> Windows and that is a problem for IUP using custom dialogs.
>
> "I tested here using the tools executable, like IupView or IupVisualLED,
> when a child dialog is closed the main dialog gets its focus back."
>
> The predefined dialogs will do that but a custom dialog will not. What do
> the predefined dialogs do that the custom dialog does not (or is not
> documented to do)?
>
> Thanks,
> Andrew
>
>
> On 2/16/2022 at 12:51 PM, Antonio Scuri wrote:
>
> Obs: You replied only to me, so I'm including the list in the reply again.
>
> > You say "I guess" but is that how it is actually done in for all the
> predefined dialogs in IUP?
>
> > Why interrupt that default sequence of events just so you can add a
> very necessary IupSetFocus that you can never leave out or it will never
> work? That default behavior doesn't make sense, it is not documented
> to function like that, and the default behavior actually doesn't work.
>
> There is no default behavior set by IUP. When a dialog is closed the
> system brings the parent or another child to foreground and it sets the
> focus. IUP actually doesn't interfere in the system behavior.
>
> I tested here using the tools executable, like IupView or IupVisualLED,
> when a child dialog is closed the main dialog gets its focus back.
>
> Best,
> Scuri
>
> Em qua., 16 de fev. de 2022 às 16:15, Andrew Robinson
> escreveu:
>
>> To any other programmers out there that are experiencing this same issue,
>> here is my workaround (psuedocode):
>>
>> setAttribute pDlg1 "CLOSE_CB=Dlg1_Close_cb"
>> myButton_cb {
>> IupShow pDlg1
>> pMainDlg ACTIVE='NO' }
>> Dlg1_Close_cb {
>> pMainDlg ACTIVE='YES' }
>>
>> Do not use SIMULATEMODAL='YES'. The advantage of this workaround is that
>> you can (I mean must) selectively make any other custom dialogs an
>> exception to the rule, if need be.
>>
>> Thanks,
>> Andrew
>>
>> On 2/16/2022 at 11:55 AM, Andrew Robinson wrote:
>>
>> Neither IupSetFocus not IupGetFocus works to resolve this issue. Do you
>> have any simple working code and app of how this is done?
>>
>> NOTE: The examples IUP give are only examples of when the custom dialog
>> is the main dialog and not a child of the main dialog.
>> Tecgraf/PUC-Rio really need to rethink what they are doing here. Consider
>> this scenario that I'm experiencing where I do nothing but call IupShow:
>>
>> 1) Close the custom dialog
>> 2) IUP hides the dialog with IupHide
>> 3) The main parent never gets its focus back
>>
>> Why interrupt that default sequence of events just so you can add a very
>> necessary IupSetFocus that you can never leave out or it will never work?
>> That default behavior doesn't make sense, it is not documented to function
>> like that, and the default behavior actually doesn't work. Why wouldn't the
>> default behavior have IupSetFocus a part of the default close routine?
>>
>> Thanks,
>> Andrew
>>
>>
>> On 2/16/2022 at 7:44 AM, Andrew Robinson wrote:
>>
>> "IUP does not set focus after the dialog is closed"
>>
>> I understand but you need to understand this needs to be documented
>> behavior since that is an expected behavior of custom modal dialogs
>> in other IDEs.
>>
>> "I guess you will have to set the focus yourself"
>>
>> You say "I guess" but is that how it is actually done in for all the
>> predefined dialogs in IUP?
>>
>> Thanks,
>> Andrew
>>
>> On 2/16/2022 at 4:47 AM, Antonio Scuri wrote:
>>
>> I guess you will have to set the focus yourself, calling IupFocus. You
>> could do that on CLOSE_CB.
>>
>> IUP does not set focus after the dialog is closed, this is highly
>> dependent on the system.
>>
>> Em ter., 15 de fev. de 2022 às 20:59, Andrew Robinson <
>> arobinso...@cox.net> escreveu:
>>
>>> Ola Antonio,
>>>
>>> I have a custom dialog that I make visible with IupShow(). Then what?
>>> Clicking the close_button closes the custom dialog but the focus never
>>> returns to the parent dialog. I tried using CLOSE_CB to call IupHide and
>>> the return IUP_IGNORE, but nothing seems to work as expected or as
>>> documented. How is this supposed to be done?
>>>
>>> Thanks,
>>> Andrew
>>> ___
>>> Iup-users mailing list
>>>
Re: [Iup-users] SIMULATEMODAL
"You replied only to me"
Sorry. Will try to not let that happen again.
"When a dialog is closed the system brings the parent or another child to
foreground and it sets the focus. IUP actually doesn't interfere in the system
behavior."
This isn't about system behavior, this is about following proper programming
procedures. The Win10 documentation says you must call EndDialog to end a
modal dialog and apparently IUP does not do that for Windows and that is a
problem for IUP using custom dialogs.
"I tested here using the tools executable, like IupView or IupVisualLED, when
a child dialog is closed the main dialog gets its focus back."
The predefined dialogs will do that but a custom dialog will not. What do the
predefined dialogs do that the custom dialog does not (or is not documented to
do)?
Thanks,
Andrew
On 2/16/2022 at 12:51 PM, Antonio Scuri wrote:
Obs: You replied only to me, so I'm including the list in the reply again.
> You say "I guess" but is that how it is actually done in for all the
predefined dialogs in IUP?
> Why interrupt that default sequence of events just so you can add a very
necessary IupSetFocus that you can never leave out or it will never work? That
default behavior doesn't make sense, it is not documented to function like
that, and the default behavior actually doesn't work.
There is no default behavior set by IUP. When a dialog is closed the system
brings the parent or another child to foreground and it sets the focus. IUP
actually doesn't interfere in the system behavior.
I tested here using the tools executable, like IupView or IupVisualLED, when a
child dialog is closed the main dialog gets its focus back.
Best,
Scuri
Em qua., 16 de fev. de 2022 às 16:15, Andrew Robinson
escreveu:
To any other programmers out there that are experiencing this same issue, here
is my workaround (psuedocode):
setAttribute pDlg1 "CLOSE_CB=Dlg1_Close_cb"
myButton_cb {
IupShow pDlg1
pMainDlg ACTIVE='NO' }
Dlg1_Close_cb {
pMainDlg ACTIVE='YES' }
Do not use SIMULATEMODAL='YES'. The advantage of this workaround is that you
can (I mean must) selectively make any other custom dialogs an exception to
the rule, if need be.
Thanks,
Andrew
On 2/16/2022 at 11:55 AM, Andrew Robinson wrote:
Neither IupSetFocus not IupGetFocus works to resolve this issue. Do you have
any simple working code and app of how this is done?
NOTE: The examples IUP give are only examples of when the custom dialog is the
main dialog and not a child of the main dialog. Tecgraf/PUC-Rio really need to
rethink what they are doing here. Consider this scenario that I'm experiencing
where I do nothing but call IupShow:
1) Close the custom dialog
2) IUP hides the dialog with IupHide
3) The main parent never gets its focus back
Why interrupt that default sequence of events just so you can add a very
necessary IupSetFocus that you can never leave out or it will never work? That
default behavior doesn't make sense, it is not documented to function like
that, and the default behavior actually doesn't work. Why wouldn't the default
behavior have IupSetFocus a part of the default close routine?
Thanks,
Andrew
On 2/16/2022 at 7:44 AM, Andrew Robinson wrote:
"IUP does not set focus after the dialog is closed"
I understand but you need to understand this needs to be documented behavior
since that is an expected behavior of custom modal dialogs in other IDEs.
"I guess you will have to set the focus yourself"
You say "I guess" but is that how it is actually done in for all the
predefined dialogs in IUP?
Thanks,
Andrew
On 2/16/2022 at 4:47 AM, Antonio Scuri wrote:
I guess you will have to set the focus yourself, calling IupFocus. You could
do that on CLOSE_CB.
IUP does not set focus after the dialog is closed, this is highly dependent
on the system.
Em ter., 15 de fev. de 2022 às 20:59, Andrew Robinson
escreveu:
Ola Antonio,
I have a custom dialog that I make visible with IupShow(). Then what? Clicking
the close_button closes the custom dialog but the focus never returns to the
parent dialog. I tried using CLOSE_CB to call IupHide and the return
IUP_IGNORE, but nothing seems to work as expected or as documented. How is
this supposed to be done?
Thanks,
Andrew
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] SIMULATEMODAL
Obs: You replied only to me, so I'm including the list in the reply again.
> You say "I guess" but is that how it is actually done in for all the
predefined dialogs in IUP?
> Why interrupt that default sequence of events just so you can add a very
necessary IupSetFocus that you can never leave out or it will never work?
That default behavior doesn't make sense, it is not documented to function
like that, and the default behavior actually doesn't work.
There is no default behavior set by IUP. When a dialog is closed the
system brings the parent or another child to foreground and it sets the
focus. IUP actually doesn't interfere in the system behavior.
I tested here using the tools executable, like IupView or IupVisualLED,
when a child dialog is closed the main dialog gets its focus back.
Best,
Scuri
Em qua., 16 de fev. de 2022 às 16:15, Andrew Robinson
escreveu:
> To any other programmers out there that are experiencing this same issue,
> here is my workaround (psuedocode):
>
> setAttribute pDlg1 "CLOSE_CB=Dlg1_Close_cb"
> myButton_cb {
> IupShow pDlg1
> pMainDlg ACTIVE='NO' }
> Dlg1_Close_cb {
> pMainDlg ACTIVE='YES' }
>
> Do not use SIMULATEMODAL='YES'. The advantage of this workaround is that
> you can (I mean must) selectively make any other custom dialogs an
> exception to the rule, if need be.
>
> Thanks,
> Andrew
>
> On 2/16/2022 at 11:55 AM, Andrew Robinson wrote:
>
> Neither IupSetFocus not IupGetFocus works to resolve this issue. Do you
> have any simple working code and app of how this is done?
>
> NOTE: The examples IUP give are only examples of when the custom dialog is
> the main dialog and not a child of the main dialog. Tecgraf/PUC-Rio really
> need to rethink what they are doing here. Consider this scenario that I'm
> experiencing where I do nothing but call IupShow:
>
> 1) Close the custom dialog
> 2) IUP hides the dialog with IupHide
> 3) The main parent never gets its focus back
>
> Why interrupt that default sequence of events just so you can add a very
> necessary IupSetFocus that you can never leave out or it will never work?
> That default behavior doesn't make sense, it is not documented to function
> like that, and the default behavior actually doesn't work. Why wouldn't the
> default behavior have IupSetFocus a part of the default close routine?
>
> Thanks,
> Andrew
>
>
> On 2/16/2022 at 7:44 AM, Andrew Robinson wrote:
>
> "IUP does not set focus after the dialog is closed"
>
> I understand but you need to understand this needs to be documented
> behavior since that is an expected behavior of custom modal dialogs
> in other IDEs.
>
> "I guess you will have to set the focus yourself"
>
> You say "I guess" but is that how it is actually done in for all the
> predefined dialogs in IUP?
>
> Thanks,
> Andrew
>
> On 2/16/2022 at 4:47 AM, Antonio Scuri wrote:
>
> I guess you will have to set the focus yourself, calling IupFocus. You
> could do that on CLOSE_CB.
>
> IUP does not set focus after the dialog is closed, this is highly
> dependent on the system.
>
> Em ter., 15 de fev. de 2022 às 20:59, Andrew Robinson
> escreveu:
>
>> Ola Antonio,
>>
>> I have a custom dialog that I make visible with IupShow(). Then what?
>> Clicking the close_button closes the custom dialog but the focus never
>> returns to the parent dialog. I tried using CLOSE_CB to call IupHide and
>> the return IUP_IGNORE, but nothing seems to work as expected or as
>> documented. How is this supposed to be done?
>>
>> Thanks,
>> Andrew
>> ___
>> Iup-users mailing list
>> Iup-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/iup-users
>>
>
>
>
>
___
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
Re: [Iup-users] SIMULATEMODAL
I guess you will have to set the focus yourself, calling IupFocus. You could do that on CLOSE_CB. IUP does not set focus after the dialog is closed, this is highly dependent on the system. Em ter., 15 de fev. de 2022 às 20:59, Andrew Robinson escreveu: > Ola Antonio, > > I have a custom dialog that I make visible with IupShow(). Then what? > Clicking the close_button closes the custom dialog but the focus never > returns to the parent dialog. I tried using CLOSE_CB to call IupHide and > the return IUP_IGNORE, but nothing seems to work as expected or as > documented. How is this supposed to be done? > > Thanks, > Andrew > ___ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users > ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
[Iup-users] SIMULATEMODAL
Ola Antonio, I have a custom dialog that I make visible with IupShow(). Then what? Clicking the close_button closes the custom dialog but the focus never returns to the parent dialog. I tried using CLOSE_CB to call IupHide and the return IUP_IGNORE, but nothing seems to work as expected or as documented. How is this supposed to be done? Thanks, Andrew ___ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
