Proceeding with the dialog entries
3 views
Skip to first unread message
kompas
Nov 3, 2009, 7:23:58 AM11/3/09
to MapInfo-L
Hi,
I've been posting several related threads recently but I feel each of
them is a bit independent so here I am again.
I can see 2 ways of finalizing dialog process:
1 by calling sub of the clicked OKbutton
2 by If CommandInfo(CMD_INFO_DLG_OK) after Dialog statement
What are the actual differences of using each of the above approaches?
Any cons and pros?
TIA,
Jakub
I've been posting several related threads recently but I feel each of
them is a bit independent so here I am again.
I can see 2 ways of finalizing dialog process:
1 by calling sub of the clicked OKbutton
2 by If CommandInfo(CMD_INFO_DLG_OK) after Dialog statement
What are the actual differences of using each of the above approaches?
Any cons and pros?
TIA,
Jakub
Lars I. Nielsen (GisPro)
Nov 3, 2009, 7:45:53 AM11/3/09
to mapi...@googlegroups.com
Hi Jakub,
I'm not entirely sure what you mean by the two alternatives. As I wrote earlier the Dialog complex is DDL (definition) while the "If" and other statements are DML (manipulation). The first DML after "Dialog" terminates the DDL section (i.e. the dialog definition).
When running the dialog, OkButton will terminate the dialog automatically.
The only reason for having a handler on OkButton, would be to have a chance to check for dialog entry completeness, issuing a Dialog Preserve if not.
If CommandInfo(...) ... is often the first DML statement after the dialog, and it executes _after_ the dialog has terminated and assigned all Into variables.
Ps! And a pitfall: If you issue a Dialog Remove, e.g. in a ListBox handler, the dialog terminates, but CommandInfo(CMD_INFO_DLG_OK) is False.
kompas skrev:
I'm not entirely sure what you mean by the two alternatives. As I wrote earlier the Dialog complex is DDL (definition) while the "If" and other statements are DML (manipulation). The first DML after "Dialog" terminates the DDL section (i.e. the dialog definition).
When running the dialog, OkButton will terminate the dialog automatically.
The only reason for having a handler on OkButton, would be to have a chance to check for dialog entry completeness, issuing a Dialog Preserve if not.
If CommandInfo(...) ... is often the first DML statement after the dialog, and it executes _after_ the dialog has terminated and assigned all Into variables.
Ps! And a pitfall: If you issue a Dialog Remove, e.g. in a ListBox handler, the dialog terminates, but CommandInfo(CMD_INFO_DLG_OK) is False.
Best regards / Med venlig hilsen Lars I. Nielsen GIS & DB Integrator GisPro
kompas skrev:
kompas
Nov 3, 2009, 5:24:54 PM11/3/09
to MapInfo-L
It means that to perform the tasks I need I should use "if
commandinfo..." and OKButton handler is not needed until I want to
check the completness/adequacy of the dialog entries, right? In other
words, OKButton handler is not the way to run the tasks my app is
designed to do, right?
Jakub
commandinfo..." and OKButton handler is not needed until I want to
check the completness/adequacy of the dialog entries, right? In other
words, OKButton handler is not the way to run the tasks my app is
designed to do, right?
Jakub
Lars I. Nielsen (GisPro)
Nov 4, 2009, 2:16:40 AM11/4/09
to mapi...@googlegroups.com
Hi Jakub,
I assume your response is to my posting. But please do include the post you're responding to in your own post, it answering a little easier.
As for your question: it depends on what you're doing.
As a general rule I would say, let the dialog handlers do dialog related stuff only, and add post-dialog actions to the code after the dialog DDL.
But more than one road leads to Rome, as they say, so you're free to build it as you want. It'll probably work both ways.
I assume your response is to my posting. But please do include the post you're responding to in your own post, it answering a little easier.
As for your question: it depends on what you're doing.
As a general rule I would say, let the dialog handlers do dialog related stuff only, and add post-dialog actions to the code after the dialog DDL.
But more than one road leads to Rome, as they say, so you're free to build it as you want. It'll probably work both ways.
Best regards / Med venlig hilsen Lars I. Nielsen GIS & DB Integrator GisPro
kompas skrev:
It means that to perform the tasks I need I should use "if commandinfo..." and OKButton handler is not needed until I want to check the completness/adequacy of the dialog entries, right? In other words, OKButton handler is not the way to run the tasks my app is designed to do, right? Jakub
kompas
Nov 24, 2009, 5:00:49 PM11/24/09
to MapInfo-L
Hi Lars,
thank you for clarification.
Jakub
On 4 Lis, 08:16, "Lars I. Nielsen (GisPro)" <L...@gispro.dk> wrote:
> Hi Jakub,
> I assume your response is to my posting. But please do include the post you're responding to in your own post, it answering a little easier.
> As for your question: it depends on what you're doing.
> As a general rule I would say, let the dialog handlers do dialog related stuff only, and add post-dialog actions to the code after the dialog DDL.
> But more than one road leads to Rome, as they say, so you're free to build it as you want. It'll probably work both ways.Best regards / Med venlig hilsen Lars I. Nielsen GIS & DB Integrator GisPro
thank you for clarification.
Jakub
On 4 Lis, 08:16, "Lars I. Nielsen (GisPro)" <L...@gispro.dk> wrote:
> Hi Jakub,
> I assume your response is to my posting. But please do include the post you're responding to in your own post, it answering a little easier.
> As for your question: it depends on what you're doing.
> As a general rule I would say, let the dialog handlers do dialog related stuff only, and add post-dialog actions to the code after the dialog DDL.
Reply all
Reply to author
Forward
0 new messages