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 <arobinso...@cox.net>
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 <arobinso...@cox.net> 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 <arobinso...@cox.net> 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 <antonio.sc...@gmail.com> 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
>> 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
