Timer Control

[Rolf Brandt]

Very interesting, I tried Martys example on two different computers with different results.
On my netbook (Atom processor) the timer won't stop after 5, it continues to run until I set interval to 0 or KillTimer.
On my desktop (Athlon) it works as Marty describes.

I guess the netbook is to slow, it fires the timer before it was able to update the label.

(Or maybe Gremlins after all...)

[Rolf Brandt]

Now, click the button "Stop Timer"  and indeed the timer stops.
    Now note that in the  WM_Timer function is the statement   "KillTimer ....",   one would think that that statement would stop the timer but it doesn't.   The KillTimer statement appears to only work if executed outside of the WM_TIMER  function.

KillTimer really does kill the timer and not only stop it.
But the timer id is reusable, and if you use SetTimer with the same id then a new timer will be created.

[Martin Francom]

Hi Marty,

I am getting completely different results with the EXE in your download versus the EXE that I create on my computer using your source. Your EXE continually increments the counter whereas mine stops after 5. See the attached archive containing my exe and Marty's. Do they run the same on your computer? (I am running Win 7).

Very strange. Marty, I assume that you compiled on WinXP, right?

(David, I haven't downloaded your project yet).

Paul,
    I am using Win-7  (upgrade from Vista)
...Marty

[Martin Francom]

Setting the timer interval should not disable the timer. According to http://msdn.microsoft.com/en-us/library/ms644906(VS.85).aspx using a value < USER_TIMER_MINIMUM then the value is set to USER_TIMER_MINIMUM (which I believe is 10 milliseconds - defined winuser.h).

Marty - do you have gremlins in your machine or something? 

Paul,
   I am beginning to think that I do.
Sometime when you have nothing better to
do,  maybe you "Remote Connect" to my
computer.   

[Martin Francom]

Paul,
   I can now recreate/fix the problem on demand.  Here's a screen print of the error message.  Does anything about this message make any sense to you?
   I am starting to believe that the wierd problems I have been experiencing of late are all related to Windows-7.   Thinking back these problems began after I had a Windows-7 upgrade. (Upgrade from Vista)
   Would a few of you good folks that are running Windows-7  be so kind as to download and compile the "TimerExample" project that I attached above.  And, see if you get the same problem I am seeing.

   Ok, what do I have to do to make the error message below go away?   Well, all I have to do is to change the caption of the from from "Timer Example"   to "Timr Example"   and the problem goes away.   To get the problem again all I need to do is change the caption back to "Timer Example".      Weird or what!

[Cho Sing Kum]

Hi Marty,

I downloaded your TimerExample.zip file. This is what I found:

Your Form1.frm has a timestamped 12Jan2010 2:40pm.
Your compiled TimerExample.exe has a timestamp of 11Jan2010 10:38am, which is more than 24 hours before Form1.frm was last saved.

I can only deduce that the compiled exe CANNOT be from the Form1.frm you provided in the zip but from an earlier one that has very different source code.

Compiling a fresh exe from the Form1.frm you provided, the exe runs correctly as per the source code.

From the error message screen shot, you have your "working" files in "C:\PBWIN90\..."

WinVista and Win7 are very fuzzy where you want to write exe files (you do this when you are compiling). I do not know whether this may be the problem.

Try moving all your projects to your "My Documents". This is the recomemnded location for your "working" files, including when compiling exe. Recommended by Microsoft.

All other location in the system drive C:, including C:\PBWIN90\... and C:\Program Files\..., are NOT recomended for your "working" files. Although WinVista and Win7 has Virtualiztion, it is better to avoid the need for WinVista and Win7 to put your files into Virtualiztion folder.

Notice that, even before WinVista and in WinXP at least, when you open Windows Explorer it always default to "My Documents" ?

I do not know whether this is the problem but I think can try to remove potential problems from "unexpected direction".

[Martin Francom]

      I know what the problem with Timer is.  And it's not the  TIMER  control.  It turns out to be my mistake.  I didn't understand how FF and the Snippets worked.   I was using snippets to store my notes and then when needed to I would use "Cut & Paste"  to add stuff from MySnippets to the code I was working on.   
     I didn't realize that FF would automatically add those snippets to the CodeGen file.  Well, I had a snippet named  "Timer"  which contain my notes about using the Timer Control.  This snippet was not a true function just some notes.  Appearently, when FF builds the CodeGen files it looks for the file name of the snippets you have in your Function Library and if that name is present in the FF project then  FF will add those functions to the end of the  CodeGen_---_Utility.INC  file.   (Paul, do I have that understanding correct?)
    Because my snippet was not a true function the PB compiler would stop at a statement that was not compilable and generate the error message I was recieving. 
    What made it more confusing for me was that the Key word (Timer) I was using was in a the Caption of the form.  Once I remove the word "Timer" from the Caption of FORM1 that snippet was no longer added to the CodeGen file and the program compiled correctly.   
    I appologize for running you guys on a wild goose chase and want to thank you for your help.

I now know better how the Function Library works.  This is what I learned:
  1) do not use snippets for storing notes unless you preface the line with a comment mark '
  2) make sure that all snippets are compilable
  3) don't use snippet names in captions as FF will add those snippets to the project

Is there anything else I need to be aware of concerning the Function Library and snippets?

[Martin Francom]

Rolf,
   Thanks for emailing me.  The easiest and simplest way to observe the behavoir of FF adding a Function Library Function to the CodeGen_--_Utility.INC  file when the function name appears in the Caption is to do the following:

    1) create a new FF project (don't add any controls to Form1)
    2) change the CAPTION of Form1 to  File\FF_FilePath
    3) compile the program
    4) go to the Release directory and  view the CodeGen_--_Utility.INC file
       You will find the function  FF_FilePath has been added

    5) now change the Caption of the FORM1 to something else and compile the
       program and look at the CodeGen_--_Utility file.  Now, you will note that
       the function  FF_FilePath was not added.   


   
       

[Jean-pierre Leroy]

Marty,

You're right I made the test and have exactly the same behavior as you.

I'm pretty sure Paul will find an easy fix for that.

Jean-Pierre

[Rolf Brandt]

That is interesting...

[Paul Squires]

Very interesting indeed. Looks like there is an oversight in my built-in parser. It must not be skipping the string literals during the parse to determine which FireFly Functions and user defined functions to include in the final code.

Should be "easy" to fix. I will report back.

[Paul Squires]

Okay, I have now modified the parser and any text inside a double quoted string literal is now blanked out prior to being examined for any FireFly Functions. It all appears to be working correctly now.

The fix will be in v3.07.

[Martin Francom]

Paul,
   Even code that is behind a comment will cause the problem, such as:


         Function FORM1_COMMAND1_BN_CLICKED ( _
                                   ControlIndex     As Long,  _  ' index in Control Array
                                   hWndForm         As Dword, _  ' handle of Form
                                   hWndControl      As Dword, _  ' handle of Control
                                   idButtonControl  As Long   _  ' identifier of button
                                   ) As Long


   '  "File\FF_FilePath"


End Function


You will want to account for that situation also.

[John Montenigro]

Paul,
I have a small app that I wanted to "time out" if not registered. Originally, I put a Timer control on the main form, and in WM_CREATE, I checked the registration. If OK, then I'd KILLTIMER. But I found that the timer would never die. So instead, I removed the Timer control from the form and then if the registration failed, I called SetTimer to create the desired timed exit... a reasonable workaround, I think.

But then I found out that FF3 had a feature that I wasn't using...

Whereas with FF2 I placed all my initialization code in the main form's WM_CREATE, with FF3, it appears that I should place all my initialization code in FF_AppStart.

Is that correct? And would that avoid the kill timer problem?

-John

I want to make a correction to my earlier post, lest it misguide the unsuspecting...

Where I had mentioned "FF_AppStart", I actually meant "FF_WinMain".

The FF_AppStart module is not a Function, so executable code won't compile.

Rather, I put my RegCheck function in the FF_WinMain module, below the FF_WINMAIN function, and I inserted a call to RegCheck in the FF_WINMAIN function. Works fine.

This totally avoids my FF2 habit of putting initialization code in the frmMAIN_WM_CREATE function, and so far, seems to avoid KillTimer problems... (and as Paul pointed out to several of us, the Timer doesn't yet exist in _WM_CREATE, so trying to kill it there has no effect...)

Sorry if I confused anyone...
-JohnM.