Dialog DoEvents no longer works as it did

[Thomas Tierney Member Find all posts View Profile Close Thomas Tierney]

Compiling under 8.03, i had the lines

    Do               
     Dialog DoEvents
      'the dialog was destroyed
     Dialog Get Size hMainDialog To x, x
    Loop While x

which worked perfectly, when I compiled under 8.04 I saw that at idle my applications cpu usage was about 99% until I selected something in the UI, then it dropped down to zero. I then changed to this:

    Do               
     Dialog DoEvents 1 to Count&
     Dialog Get Size hMainDialog To x, x
    Loop While x

And the problem whent away. I replaced 1 with 0 and the problem came back. The help file (beautiful chm file btw) states

If sleep& is not specified then the current thread will be paused for 1 mSec

So my question is what is correct? The doc or the code contains a defect and I am not sure which one..

Thanks

[Wayne Suite Member Find all posts View Profile Close Wayne Suite]

Processor usage for Dialog DoEvents

If you add Sleep 1 after the Dialog DoEvents the processor usage drops back to almost 1%. Just something I noticed, but I am a newbie here. Hope this helps.

Wayne.

[Eros Olmi Member Find all posts View Profile Close Eros Olmi]

Just noted the same yesterday and sent info to PB support.

Dialog DoEvents 1& do not solve the problem

[Thomas Tierney Member Find all posts View Profile Close Thomas Tierney]

Thanks Eros, wasnt sure, I thought my eyes were getting buggy

[Petr Schreiber jr Member Find all posts View Profile Close Petr Schreiber jr]

Hi,

I can confirm something changed here too ( PB/WIN 8.03 -> 8.04 ).

In Samples\DDT\Address\Address.bas I get 99% cpu when clicked on "Find" button ( MODELESS dialog ).

On my PC

DIALOG DOEVENTS [B]1[/B]

... luckily helps ( task manager reports 0% CPU ).


Petr

[Bill Eppler Member Find all posts View Profile Close Bill Eppler]

FWIW I see exactly the same effect.
Please note other differences I've encountered in my "...broke my app" post

[E Dingsor Member Find all posts View Profile Close E Dingsor]

Hi, happend to me too. I have a "spamkiller" tray app that checks my email accounts on regular intervals and after recompiling the project with 8.04 the app consumed constantly 50% of my CPU time. However the helpfile has a link to SLEEP statement under DOEVENTS in the helpfile and there it is stated:

QUOTE: "The time-slice duration (also known as the Quantum) can vary from version to version of Windows, ranging from 20 mSec to 120 mSec. Therefore, the Quantum can affect the performance of applications when SLEEP 0 is overused. That is, excessive use of SLEEP 0 can cause an application to cede much of its available processor time, causing a significant drop in application performance."
END QUOTE

That gave me the idea to change SLEEP to another number than 0 i.e 5 and the program works as intended i.e no overuse of CPU time. Using Windows XP PRO

Eigil

[Edwin Knoppert Member Find all posts View Profile Close Edwin Knoppert]

This is not just a value, #0 produces explicit windows behaviour against any other value like #1 or up.

Not sure why you people use it this way.

Not sure why pb doesn't offer us a real messagepump-intercept feature.
It's so easy and asked so often (how to solve things).

For me only for atl support i would need the low level messagepump at this time.
This to instruct the ActiveX control to handle the keyboard instructions.

[Eros Olmi Member Find all posts View Profile Close Eros Olmi]

Personally I do not use DIALOG DOEVENTS but a classical:

  MACRO NewDoEvents
    GLOBAL nde_Msg AS TagMsg
    IF PeekMessage(nde_Msg, %NULL, 0, 0, %PM_REMOVE) THEN
      TranslateMessage nde_Msg
      DispatchMessage nde_Msg
    END IF
  END MACRO

This (as code of others here) was working till PB803 while recompiling the same exact code under PB804 something force CPU to 100%.

So in this post the question is why something changed and no mention in What's New file? It is obvious that something changed so we would like to know if there is a new way to manage MODELESS dialogs or we can wait for a fix to come out shortly.

Thanks
Eros

[Edwin Knoppert Member Find all posts View Profile Close Edwin Knoppert]

>GLOBAL nde_Msg AS TagMsg

This is the most terrible thing one can do

Make it local or a macrotemp(my favourite for this)

[Eros Olmi Member Find all posts View Profile Close Eros Olmi]

Edwin,

do not care about my terrible code, that's not the point of this thread.
Others use different code and the problem is the same: 100% CPU usage.

Ciao
Eros

[Edwin Knoppert Member Find all posts View Profile Close Edwin Knoppert]

I tried a real messagepump but the on close it never exits the messagepump for some reason.

[Michael Mattias Member Find all posts View Profile Close Michael Mattias]

Personally I do not use DIALOG DOEVENTS but a classical..

IF PeekMessage(nde_Msg, %NULL, 0, 0, %PM_REMOVE) THEN
      TranslateMessage nde_Msg
      DispatchMessage nde_Msg
END IF

That's hardly "classical",

A standard message loop uses GetMessage, which does not return until a message is available and waits efficiently, rather than sitting in a loop on PeekMessage, which returns and starts another iteration immediately if no message is available. And in this code, only one message is retrieved and processed even if more than one is available.

Not to mention, PeekMessage will not pull a WM_PAINT message from the queue.

MCM

[Edwin Knoppert Member Find all posts View Profile Close Edwin Knoppert]

>rather than sitting in a loop on PeekMessage

You are mistaken, there is *no* loop..
This is a 'classical' substitute for the VB doevents.

People comming from VB often asked for a VB doevents substitute.
This doevents stuff is always totally misused, also in VB.
It's used by people not understanding the messagepump.

Unf. the messagepump seems a difficult thing to grasp which leds to silly functionality like this.

All these related api's have more parameters.
Only with the correct settings and 'moment' in code you can properly use these api's.

[Eros Olmi Member Find all posts View Profile Close Eros Olmi]

Michael,

maybe it is my intention to do so. You know, in an interpreter (you know what I mean) responding to WM_PAINT while interpreting the risk is that the parser will remain all the time to process WM_PAINT

Again, do not get my code as an example but remain focused on the problem exposed into this thread. If any observation to my post, make it in another thread or post into my forum. Is that so difficult?

[Michael Mattias Member Find all posts View Profile Close Michael Mattias]

I had noticed there is no loop, which is why only one message is retrieved.

People comming from VB often asked for a VB doevents substitute.
This doevents stuff is always totally misused, also in VB.
It's used by people not understanding the messagepump.

That is an excellent observation.

You don't need a 'VB substitute' for anything when programming using a different product: you need to figure out what The Right Thing To Do Is.

(Chalk up another check mark in the 'negatives' column of verb-for-verb conversions)

[Eros Olmi Member Find all posts View Profile Close Eros Olmi]

Just to remind ...
here we have a precise exact problem: 100% CPU when using MODELESS dialogs under PB804 while no problem under PB803.
Are you facing this problem? Perfect, post here or write to [email protected] with an example (as I did some days ago)
Do you want to talk about the beauty of windows message pump and how to manage it? Perfect, open a new thread "Inside windows message pump" and we will all read it.

Not so difficult, isn't it.

[Michael Mattias Member Find all posts View Profile Close Michael Mattias]

>Not so difficult... isn't it.

No.

FUNCTION PbMAIN()

   DIALOG NEW ...  to hDlg
    CONTROL ADD ..
    CONTROL ADD

   DIALOG SHOW MODELESS hDLG CALL something

  WHILE GetMessage(Msg, %NULL, 0, 0)
    IF ISFalse IsDialogMessage (hDlg, msg) 
       TranslateMessage Msg
        DispatchMessage Msg
    END IF
  WEND
END FUNCTION

MCM

[Edwin Knoppert Member Find all posts View Profile Close Edwin Knoppert]

>Not so difficult... isn't it.

No.

FUNCTION PbMAIN()

   DIALOG NEW ...  to hDlg
    CONTROL ADD ..
    CONTROL ADD

   DIALOG SHOW MODELESS hDLG CALL something

  WHILE GetMessage(Msg, %NULL, 0, 0)
    IF ISFalse IsDialogMessage (hDlg, msg) 
       TranslateMessage Msg
        DispatchMessage Msg
    END IF
  WEND
END FUNCTION

MCM

This *is* what i tested today:

    Dialog Show Modeless hWnd Call Form1_Proc
    Local Msg As tagmsg

  While GetMessage(Msg, %Null, 0, 0)
    If IsFalse( IsDialogMessage(hWnd, msg)  ) Then
       TranslateMessage Msg
        DispatchMessage Msg
    End If
  Wend

On Alt+F4 the exe remains running (check taskmanager)

(I know that there is something with dialogboxes needing an explicit close, sm > WM_CLOSE afaik)

[Eros Olmi Member Find all posts View Profile Close Eros Olmi]

Compilable code under PB804.
The DOEVENT loop will go 100% CPU.
Changing to "Dialog DoEvents 1 To Count" works fine

The MMC code is working fine if DIALOG END is added at the end of the loop.

#Include "WIN32API.INC"
 
CallBack Function cb_dlg() As Long
  '...
  'Function = DefWindowProc(CbHndl, CbMsg, CbWParam, CbLParam)
End Function
 
Function PBMain()
   Dim hDlg As Dword
   Dim lMsg As TagMsg       
   Dim Count As Long                          
 
  Dialog New 0, "Test", -1, -1, 200, 100  To hDlg
  Dialog Show Modeless hDLG Call cb_dlg
 
  '---From PB help file
    Do
      Dialog DoEvents 0 To Count
    Loop While Count
 
  '---MMC code
  '  While GetMessage(lMsg, %Null, 0, 0)
  '    If IsFalse IsDialogMessage (hDlg, lmsg) Then
  '       TranslateMessage lMsg
  '       DispatchMessage lMsg
  '    End If
  '  Wend 
  '  dialog end hDlg
 
End Function