MdiChild menu

[Ingo Junge-Herrmann]

Ignacio,
why the MdiChild menu doesn't work?
Thanks in advance
Ingo
--

Attached files MDISample1.zip (3 KB)Â

[jfgimenez]

Ingo,
fixed! Add this .obj file to your project.
Thanks for the info.
--
Regards,
Jose F. Gimenez


Attached files wincontrol.zip (4.6 KB)Â

[jfgimenez]

Ingo,
fixed! Add this .obj file to your project.
Thanks for the info.
--
Regards,
Jose F. Gimenez


Attached files wincontrol.zip (4.6 KB)Â

[Ingo Junge-Herrmann]

Jose,
the bitmaps are shown now but the messages of the mdichild menu are still
not shown on the mdi statusbar.
Regards
Ingo
"Jose F. Gimenez" <jfgimenez@wanadoo.es> wrote:
>Ingo,
>
>fixed! Add this .obj file to your project.
>
>Thanks for the info.
>
>
>--
>Regards,
>
>Jose F. Gimenez
>
>
>

[Ingo Junge-Herrmann]

Jose,
the bitmaps are shown now but the messages of the mdichild menu are still
not shown on the mdi statusbar.
Regards
Ingo
"Jose F. Gimenez" <jfgimenez@wanadoo.es> wrote:
>Ingo,
>
>fixed! Add this .obj file to your project.
>
>Thanks for the info.
>
>
>--
>Regards,
>
>Jose F. Gimenez
>
>
>

[jfgimenez]

Ingo,
> the bitmaps are shown now but the messages of the mdichild menu are still
> not shown on the mdi statusbar.
you are right. I hope this .obj fixes the problem. You need to add both
files to your project: the previous wincontrol.obj and this new form.obj
Thanks for your feedback.
--
Regards,
Jose F. Gimenez


Attached files form.zip (10 KB)Â

[jfgimenez]

Ingo,
> the bitmaps are shown now but the messages of the mdichild menu are still
> not shown on the mdi statusbar.
you are right. I hope this .obj fixes the problem. You need to add both
files to your project: the previous wincontrol.obj and this new form.obj
Thanks for your feedback.
--
Regards,
Jose F. Gimenez


Attached files form.zip (10 KB)Â

[Ingo Junge-Herrmann]

Jose,
the new form.obj has a bug.
TMDIFRAME:WMMENUSELECT(753)
Fehler BASE/1004 Class: 'NIL' has no exported method: OMENU
Argumente: ()
You must only go withe the mousepointer over the menuitems of the submenu
"Register".
Without the new form.obj the errror doesn't occur.
Regards
Ingo
--

Attached files MDISample1.zip (18.1 KB)Â

[Ingo Junge-Herrmann]

Jose,
the new form.obj has a bug.
TMDIFRAME:WMMENUSELECT(753)
Fehler BASE/1004 Class: 'NIL' has no exported method: OMENU
Argumente: ()
You must only go withe the mousepointer over the menuitems of the submenu
"Register".
Without the new form.obj the errror doesn't occur.
Regards
Ingo
--

Attached files MDISample1.zip (18.1 KB)Â

[jfgimenez]

Ingo,
> the new form.obj has a bug.
> TMDIFRAME:WMMENUSELECT(753)
> Fehler BASE/1004 Class: 'NIL' has no exported method: OMENU
> Argumente: ()
>
> You must only go withe the mousepointer over the menuitems of the submenu
> "Register".
>
> Without the new form.obj the errror doesn't occur.
Fixed! I hope there is no more bugs
Replace the file form.obj with this new one.
--
Regards,
Jose F. Gimenez


Attached files form.zip (10 KB)Â

[jfgimenez]

Ingo,
> the new form.obj has a bug.
> TMDIFRAME:WMMENUSELECT(753)
> Fehler BASE/1004 Class: 'NIL' has no exported method: OMENU
> Argumente: ()
>
> You must only go withe the mousepointer over the menuitems of the submenu
> "Register".
>
> Without the new form.obj the errror doesn't occur.
Fixed! I hope there is no more bugs
Replace the file form.obj with this new one.
--
Regards,
Jose F. Gimenez


Attached files form.zip (10 KB)Â

[Ingo Junge-Herrmann]

Jose,
at first view no further bug found.
BTW I have another question:
Is it necessary to call Processmessages() in my code?
If yes at which opportunity?
Sorry for this unprofessinal question but I found nothig about that in the
documentation.
Regards
Ingo

[Ingo Junge-Herrmann]

Jose,
at first view no further bug found.
BTW I have another question:
Is it necessary to call Processmessages() in my code?
If yes at which opportunity?
Sorry for this unprofessinal question but I found nothig about that in the
documentation.
Regards
Ingo

[jfgimenez]

Ingo,
> at first view no further bug found.
Great!
> Is it necessary to call Processmessages() in my code?
> If yes at which opportunity?
No, it ins't at all. There is no need to call ProcessMessages() in Xailer
almost never. It's only needed when, while processing an event, any pending
messages has to be processed too. In fact, this is very seldom.
The other (and rather often) reason to call it is when the program is busy
in a loop that takes to much time; then it must be called periodically.
I.e., if you are in a loop reading or processing database records, you
should call ProcessMessages() every X records.
--
Regards,
Jose F. Gimenez

[jfgimenez]

Ingo,
> at first view no further bug found.
Great!
> Is it necessary to call Processmessages() in my code?
> If yes at which opportunity?
No, it ins't at all. There is no need to call ProcessMessages() in Xailer
almost never. It's only needed when, while processing an event, any pending
messages has to be processed too. In fact, this is very seldom.
The other (and rather often) reason to call it is when the program is busy
in a loop that takes to much time; then it must be called periodically.
I.e., if you are in a loop reading or processing database records, you
should call ProcessMessages() every X records.
--
Regards,
Jose F. Gimenez

[ignacio]

Ingo,
You are rigth. We forgot to document that function. Here it is:
ProcessMessages
This function permits that all windows process the Windows message queue.
The operating system interacts with all windows through messages that it sends. Those windows receive those messages and act in consequence. Normally this process is completely automatic, with no user request. However, on very large programming loops than consume a lot of CPU is possible that the rest of windows do not have the chance to process their messages that the operating system is sending, like the painting messages for example, on those cases you can force that those messages get processed calling the ProcessMessages function.
Is rare that you need to call this function, except when you execute very intensive loops. In any case you should be extremely cautious when using this function since it may produce undesirable effects on your own application. As a sample we point out some typical errors that are generated when using this function:
a.. Processes that are triggered with a button click. Es typical to forget to put that button disable or even the complete form. If you make calls to ProcessMessages(), then the user will be able to click again that same button, which probably will produce undesirable effects.
b.. Processes that affect a database tables that are also showed in some other windows. If on your working loop you are navigating through a table and you call the function ProcessMessages() you should be aware that the table should not be used by any Browser on any active windows even if they are disabled, because the Browser painting routine will provoke a change on the table record pointer, that will surely generate equally undesirable effects.
Sample:
DO WHILE !Eof()
n++
IF n > 100
ProcessMessages()
n := 0
ENDIF
..........
..........
ENDDO
Regards,
"Ingo Junge-Herrmann" <[email=XPRO-0031BA74-01@10.0.0.11]XPRO-0031BA74-01@10.0.0.11[/email]> escribió en el mensaje news:43cca38b$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
>
> Jose,
>
> at first view no further bug found.
>
> BTW I have another question:
>
> Is it necessary to call Processmessages() in my code?
> If yes at which opportunity?
>
> Sorry for this unprofessinal question but I found nothig about that in the
> documentation.
>
> Regards
>
> Ingo
>
>
--

[InvalidAccount]

Ingo,
You are rigth. We forgot to document that function. Here it is:
ProcessMessages
This function permits that all windows process the Windows message queue.
The operating system interacts with all windows through messages that it sends. Those windows receive those messages and act in consequence. Normally this process is completely automatic, with no user request. However, on very large programming loops than consume a lot of CPU is possible that the rest of windows do not have the chance to process their messages that the operating system is sending, like the painting messages for example, on those cases you can force that those messages get processed calling the ProcessMessages function.
Is rare that you need to call this function, except when you execute very intensive loops. In any case you should be extremely cautious when using this function since it may produce undesirable effects on your own application. As a sample we point out some typical errors that are generated when using this function:
a.. Processes that are triggered with a button click. Es typical to forget to put that button disable or even the complete form. If you make calls to ProcessMessages(), then the user will be able to click again that same button, which probably will produce undesirable effects.
b.. Processes that affect a database tables that are also showed in some other windows. If on your working loop you are navigating through a table and you call the function ProcessMessages() you should be aware that the table should not be used by any Browser on any active windows even if they are disabled, because the Browser painting routine will provoke a change on the table record pointer, that will surely generate equally undesirable effects.
Sample:
DO WHILE !Eof()
n++
IF n > 100
ProcessMessages()
n := 0
ENDIF
..........
..........
ENDDO
Regards,
"Ingo Junge-Herrmann" <[email=XPRO-0031BA74-01@10.0.0.11]XPRO-0031BA74-01@10.0.0.11[/email]> escribió en el mensaje news:43cca38b$[email=1@ozsrvnegro.ozlan.local...]1@ozsrvnegro.ozlan.local...[/email]
>
> Jose,
>
> at first view no further bug found.
>
> BTW I have another question:
>
> Is it necessary to call Processmessages() in my code?
> If yes at which opportunity?
>
> Sorry for this unprofessinal question but I found nothig about that in the
> documentation.
>
> Regards
>
> Ingo
>
>
--