Application fails to init ??

[Scott Turchin]

You can put the timer in the WM_INITDIALOG also......
That way you can keep a local variable in the message pump.
Here's how I do it:

  Select Case CbMsg

    Case %WM_INITDIALOG
         SetTimer CbHndl, %HACKERTIMER,  30000, ByVal %NULL 'Anti-Hack every 30 seconds

    Case %WM_TIMER
        Select Case CbWparam
          Case %HACKERTIMER
            g_Result = HackerScan
        End Select

    Case %WM_DESTROY
        Killtimer cbhndl, %HACKERTIMER

One th ing to note however, if you kill a timer in a timer function it stops the function at that point.....
So, maybe use a Static variable to count how many times the timer went off and then kill it after x amount of times or something creative like that......


Scott


------------------
Scott

[Bud Durland]

Thanks for the pointers, guys. This kind of stuff is what happens
when an old DOS programmer tries to muddle his way through windows.

Just to be specific (because I don't really understand this stuff
well yet); should I try something like this:

In PBMAIN (*before* the message loop) I'll add something like this:

SetTimer hDlg1&, %ID_MYTIMER, 10000, $nul

Meaning Every ten seconds, kick off the timer, and send a
WM_TIMER message, which will be handled by XXXX_DLGPROC. I'll
need to add code to catch it (as a CASE, I suspect) and do
something with it.

Is there harm in killing and re-creating the timer, or is there a way
to "suspend" it for a bit" The nature of this program will likely be
that I shouldn't allow more than one task to run at a time.

For those who haven't tried it yet, Chris' free DDT designer is
a real benefit to us old DOS hacks. I'll probably move up to
EZGUI 2.0 when it come out.



------------------
[email protected]
http://www.northnet.org/bdurland

[Eric Pearson]

Adding to my last response...

Looking at the docs it's not clear, but it's possible that DIALOG DOEVENTS "empties" the message queue in the way I described. Maybe somebody from support or R&D will comment...

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Eric Pearson]

Bud --

Chris is absolutely right, regardless of whether or not you are using EZGUI, DDT, API/SDK, or even PowerBASIC. You would be amazed how many times the window message handler function (DIALOG DOEVENTS in this case) needs to be called for even simple operations like redisplaying a small dialog. Hundreds! And if you perform an operation like DIR$ between every one of those steps, your GUI will grind to a virtual halt.

Your best bet might be to create one thread for your GUI, and one for the "background" operations. That can get tricky if the two need to interact -- which they usually do -- but it would make a world of difference.

Another technique would be to change from DDT to SDK style coding, and to create a separate function that contains your message loop. Your main loop would call the function (I call mine ServiceDialog), and it would have its own loop. By using the PeekMessage API function the function can continue looping until there are no more window messages to process, and then exit. The main loop would then perform your checks like DIR$, then ServiceDialog would "clear" the message queue once again.

Even using that technique, this line concerns me:

IF LEN(DIR$($OrderMRGFile)) > 0 THEN CALL FaxOrderConfirm

It looks like your program will fail to maintain its GUI properly while the order confirmation is faxed. That means, for example, that if the app is covered by another app and then uncovered, the user will see a gray rectangle until the fax is 100% sent. You could add DIALOG DOEVENTS to the fax routine, but that becomes very clumsy.

I'd really look into threads if I were you...

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited March 31, 2001).]

[Chris Boss]

Bud;

First, let me say , you can post any code produced with my Freeware
Visual Designers. The code is yours to do with as you please.

Second, I notice you added a whole bunch of stuff to the message
loop part (thats the section with the DO LOOP with the DoEvents in it).

I would strongly suggest that you not put all that stuff within the
message loop !

The message loop is not the place for all sorts of coding.

The generic message loop generated by my Visual Designer was simply :

    DO
        DIALOG DOEVENTS TO Count&
    LOOP UNTIL Count&=0

Bud, here is what your Message loop looks like now :

DO
    IF LastDate <> DATE$ THEN LogIt "Date Change: " & DATE$
    IF LEN(DIR$("CUSTDB.NEW")) > 0 THEN
      Logit "Customer File update found"
      KILL CustDBFile
      NAME "CustDB.NEW" AS CustDBFile
      LoadCustDB
    END IF'' Note later in this msg about FaxOrderConfirm
    IF LEN(DIR$($OrderMRGFile)) > 0 THEN CALL FaxOrderConfirm
    DIALOG DOEVENTS TO Count
LOOP UNTIL Count = 0

If you need to periodically poll something (like a COM port or something)
then you should either use a Timer (see API docs) and do those things
when the Timer generates an event or you should use a Thread which
will allow you to constantly poll something external, while not
interfearing with the message loop.

A good rule to remember is :

Keep the code in a message loop simple !

If the message loop dies (locks up) then Windows (or at least your app)
can become inresponsive.




------------------

[Peter Redei]

Bud,
I have a wild guess...
If the email program is using the rasapi32.dll and dial-up networking is not configured on the win'2000 machine this might happens.
Did you try to rem out the email portion, compile it and see what happens?

Regards,

Peter Redei


------------------

[Bud Durland]

"Message Pump Code"; is kinda greek to me.
Are these the peices you mean?

FUNCTION PBMAIN
  LOCAL Count       AS LONG
  LOCAL CC1         AS INIT_COMMON_CONTROLSEX
  LOCAL LastDate    AS STRING

  CC1.dwSize=SIZEOF(CC1)
  CC1.dwICC=%ICC_WIN95_CLASSES
  InitCommonControlsEX CC1
  EZLIB_DefColors
  EZLIB_InitFonts

  ShowDialog_Form1 0

  Logit "Initializing...
  CustDBFile = "CUSTDB.DAT"
  LoadCustDB
  lastDate = DATE$
  LogIt "Ready!

  CONTROL SET TEXT hForm1&, %IDL_INITTIME, "Init: " & DATE$ & " " & TIME$
  DIALOG DOEVENTS

  DO
    IF LastDate <> DATE$ THEN LogIt "Date Change: " & DATE$
    IF LEN(DIR$("CUSTDB.NEW")) > 0 THEN
      Logit "Customer File update found"
      KILL CustDBFile
      NAME "CustDB.NEW" AS CustDBFile
      LoadCustDB
    END IF
'
' Note later in this msg about FaxOrderConfirm
    IF LEN(DIR$($OrderMRGFile)) > 0 THEN CALL FaxOrderConfirm
    DIALOG DOEVENTS TO Count
  LOOP UNTIL Count = 0

  EZLIB_DeleteBrushes
  EZLIB_DeleteFonts

END FUNCTION

Apologies ahead to Chris Boss if I'm not supposed to post this
part -- it was created with his freeware DDT desinger, and I
have not modified it.

' *************************************************************
'                             Dialog Callback Procedure
'                             for Form Form1
'                             uses Global Handle - hForm1&
' *************************************************************

CALLBACK FUNCTION Form1_DLGPROC
  SELECT CASE CBMSG
    ' Common Windows Messages you may want to process
    ' -----------------------------------------------
    CASE %WM_TIMER
    CASE %WM_HSCROLL
    CASE %WM_VSCROLL
    CASE %WM_SIZE
    CASE %WM_CLOSE
    CASE %WM_DESTROY
    CASE %WM_SYSCOMMAND
    CASE %WM_PAINT
    ' -----------------------------------------------
    CASE %WM_CTLCOLORDLG
      IF CBLPARAM=CBHNDL THEN
        ' Dialogs colors
        SetTextColor CBWPARAM, App_Color&(0)
        SetBkColor   CBWPARAM, App_Color&( 24)
        FUNCTION=App_Brush&( 24)
      END IF
    CASE %WM_CTLCOLORMSGBOX , %WM_CTLCOLORBTN, %WM_CTLCOLOREDIT,_
         %WM_CTLCOLORSTATIC, %WM_CTLCOLORSCROLLBAR, %WM_CTLCOLORLISTBOX
      ' Control colors
      SELECT CASE GetDlgCtrlID(CBLPARAM)
        CASE  %LABEL5
          SetTextColor CBWPARAM, App_Color&( 0)
          SetBkColor   CBWPARAM, App_Color&( 24)
          FUNCTION=App_Brush&( 24)
        CASE  %LABEL4
          SetTextColor CBWPARAM, App_Color&( 0)
          SetBkColor   CBWPARAM, App_Color&( 24)
          FUNCTION=App_Brush&( 24)
        CASE  %LABEL3
          SetTextColor CBWPARAM, App_Color&( 0)
          SetBkColor   CBWPARAM, App_Color&( 24)
          FUNCTION=App_Brush&( 24)
        CASE  %LABEL2
          SetTextColor CBWPARAM, App_Color&( 0)
          SetBkColor   CBWPARAM, App_Color&( 24)
          FUNCTION=App_Brush&( 24)
        CASE  %IDL_INITTIME
          SetTextColor CBWPARAM, App_Color&( 14)
          SetBkColor   CBWPARAM, App_Color&( 24)
          FUNCTION=App_Brush&( 24)
        CASE ELSE
          FUNCTION=0
      END SELECT
    CASE %WM_NOTIFY
      IF EZLIB_IsTooltip(CBLPARAM) THEN
        SELECT CASE EZLIB_TooltipID(CBLPARAM)
          CASE  %BUTTON1
            EZLIB_SetTooltipText CBLPARAM, "Control -  %BUTTON1"
          CASE ELSE
        END SELECT
      END IF
      IF EZLIB_IsTab(CBLPARAM) THEN
        SELECT CASE EZLIB_TabID(CBLPARAM)
          CASE ELSE
        END SELECT
      END IF
    CASE %WM_COMMAND
      ' Process Messages to Controls that have no Callback Function
      ' and Process Messages to Menu Items
      SELECT CASE CBCTL
        CASE ELSE
      END SELECT
    CASE ELSE
  END SELECT
END FUNCTION

The SUB FaxOrderConfirm (in PBMAIN) has this general flow:

1. read a file, and build a list of customers to send faxes to
2. DOEVENTS
3. For each customer:
a. Create an HTML file
(doevents)
b. SHELL to external "submit fax" program (a Win32 exe),
which in turn invokes a part of IE5 to print the HTML
to the fax print driver.
(doevents)
c. check for status mesages from the submit fax process,
record errors
(doevents)
4. Send an e-mail to the office manager reporting what happend
5. wait until next time.



------------------
-----------------------
[email protected]

[Lance Edmonds]

Now if I can jusr figure out how to keep the screen repainted
-- DIALOG DOEVENTS doesn't keep up.

Lets see your message pump code - the pump should be running continuously after the DIALOG SHOW MODELESS statement, and continue until that dialog is destroyed.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Bud Durland]

I'm beginning to believe this is a dll problem. The program
uses COMMCTRL.INC, and also calls routines in MarshallSoft's
SEE32 e-mail product. It was not too soon after I added the
e-mail support that the problem occurred; so that will be my
first place to look.

FWIW, I brought the source home, where I use a Win2K setup
similar to my machine at work (just not as fast), and it works
just fine.

Now if I can jusr figure out how to keep the screen repainted
-- DIALOG DOEVENTS doesn't keep up.



------------------
-----------------------
[email protected]

[Chris Boss]

Bud;

I checked MSDN (Online) and there is little about this error message.

The little I can gather from what I read is that the problem may
be associated with a DLL not loading properly. If you are using
my Freeware Visual Designer which loads the Common Control DLL
your problem may be associated with that.

Does the problem persist after rebooting ?

Also, I strongly suggest you only show Dialogs as Modal if they
are an owned (has a parent) Popup ! If it is the main window in
your app it should always be Modeless. The only purpose Modal
serves is to disable its Parent window while the Dialog is displayed.

If the app works on another OS (ie. 95 or NT) then likely there is
a difference between 2000 and other OS that is affecting your app.

Will a simple Dialog created with my Visual Designer (with no extra code
added) run OK on 2000 ?



------------------

[Eric Pearson]

Have you tried rebooting?

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Bud Durland]

My current project at work isan automated faxer -- I read a CSV
file for data, create an HTML file for each, then use a command
line utility that came with our fax server (via SHELL) to fax
the HTML to the recipient.

All was going pretty well, until I tried an experiment. I
created the shell of the progrma using Chris Boss's FreeWare
DDT designer (great program, BTW). I changed the DIALOG SHOW
command from MODELESS to MODAL to see what the effects would be.
When I tried to run the program, Windows 2000 said:

THis application failed to initialize properly.
Error code 0xC000007B
Click OK to terminate the application.

I wasn't worried yet. I changed the line back to MODELESS. But the
error persists; I've rebooted the machine and it still gets the
same error. BUT, if I copy the executable to a machine
running WindowsNT 4.0, it works just fine.

I don't understand. Anyone have any enlightenment for me?


------------------
-----------------------
[email protected]