dc_completeevents()

This forum is for eXpress++ general support.
Post Reply
Message
Author
reganc
Posts: 259
Joined: Thu Jan 28, 2010 3:08 am
Location: Hersham, Surrey, UK
Contact:

dc_completeevents()

#1 Post by reganc »

We have used dc_completeevents() in a processing loop to allow a cancel button shown on the processing dialog to be actioned and that was fine.

I recently added a dc_completevents() call to a generic progress dialog we have. I did this because I wanted to adjust the progress dialog so that if it was still the dialog that SetAppWindow() returned as the current app window (we have use a multi-threaded dialog approach) it would setappfocus() to this progress dialog to keep it in front of the parent dialog window.

Without this, if the parent dialog was switched back to using the taskbar or alt-tab while processing is beig done, it appeared to not be doing anything because the progress dialog which was showing what was being done was not brought to the front at the same time.

So I added a 'SetAppWindow() == oParentDialog' test into the processing loop that if the SetAppWindow was currently the parent window then bring the progress dialog to the front. This did not work at all. After a bit of head scratching I added a dc_completeevents() call and it started working fine. I guessed that unless dc_completeevents() is called the SetAppWindow will not always return the correct dialog object.

But I had to take it all back out again because we then noticed that this slows down the actual processing loop considerably. We use this generic progress dialog in one of our startup 'synchronise new database structures' routines and it slowed to a crawl. Originally it took 15-20 seconds to complete but after adding dc_completeevents() it was more like 90 seconds.

I understand that by calling the dc_completeevents() function you are allowing the windows event processing to take place but it seems that more events are being processed than required.

Does anyone have any thoughts as to how this can be done without incurring the slow downs?
Regan Cawkwell
Real Business Applications Ltd
http://www.rbauk.com

User avatar
rdonnay
Site Admin
Posts: 4813
Joined: Wed Jan 27, 2010 6:58 pm
Location: Boise, Idaho USA
Contact:

Re: dc_completeevents()

#2 Post by rdonnay »

Regan -

You could write your own CompleteEvents() function and add some debugging to see what events are occurring in your processing loop.
You can also call CompleteEvents() less often in the loop. I do this a lot.

Roger

Code: Select all

nCount := 0
DO WHILE lProcessing
  nCount++
  IF nCount % 10 == 0
    CompleteEvents()
  ENDIF
  ... do some processing stuff
ENDDO


FUNCTION CompleteEvents( aGetList, oDialog )

LOCAL i, mp1, mp2, oXbp, nEvent, nSeconds := Seconds()

nEvent := -1
DO WHILE nEvent # 0 .AND. Seconds() - nSeconds < 2
  nEvent := AppEvent( @mp1, @mp2, @oXbp, .1 )
  IF nEvent > 0 .AND. Valtype(oXbp) == 'O' .AND. !(nEvent = xbeM_Motion .AND. mp1 == NIL)
    oXbp:handleEvent( nEvent, mp1, mp2 )
    WTL DC_AppEventDefine(nEvent)  <<<<< write debugging to DEBUG.LOG
  ENDIF
ENDDO

RETURN .T.


The eXpress train is coming - and it has more cars.

Post Reply