Timers on Windows Stop Firing

I’ve got the weirdest problem, and I’m worried… you’ll see why.

OK, I’m running REALStudio 2011r3. I’m sure at this point most of you will not read this - fine. Maybe I’m the last person to continue to use it. But please read on, if there’s anything you know that would help. Please do not say “start using Xojo”, that isn’t a practical solution.

Here’s the issue. I have 12 major applications I sell. For the past 8 years (since RS2011r3 came out) I’ve been kicking out new versions, both Mac and Windows. Everything has run really well, no problems at all. I build them all at one time and make them available for updating.

I compile them all on a Mac, running OSX 10.6, even the Windows builds. Again, remember that this has worked for 8 years, doing it this way.

ALL OF A SUDDEN: The latest builds I put, the Windows versions, the Timers never fire. This is on the compiled binaries. And this is with every application. They share the same corporate code framework, but the Timers are mostly not in the shared framework.

There has been no Plugin changes or anything. I run the Windows binaries on a Win7 computer, but it happens on all my computers. I even have had a client report this problem, and I’m certain I’m going to start hearing many more reports.

I cleared the Caches folder, rebooted the Mac, tried a couple Windows compiles, it doesn’t matter, no timer ever fires.

Any ideas what this could be???

First, check the previous version of your exe to see if timers are still working there this will tell you if its your issue or not.

Timers work by raising messages, if you are flooding message by say a recursive paint bug (paint also raises messages) then the timer messages wont be getting processed in a timely manner if ever and it will look like they aren’t working.

Download http://windowdetective.sourceforge.net/ and point it at your running app to see the messages being raised. If you see message spam when you aren’t doing anything then you’ve found the issue. Time to check what you changed between versions.

Thanks Julian.

  • I built something a week ago and it worked.
  • This is much more than timers not appearing to work. This is Timers set to Multiple and never firing, ever.
  • According to Window Detective, Timers don’t appear to have a Window so I can’t test the Action methods properly.

My form has many, many windows so how can you catch “message spam”?

I really don’t think that’s it though. THis has compiler bug written all over it, but we’ll see. There’s only one change I’ve made, regarding Windows shortcuts, I’ll check it.

Ah yeah, I forgot Windows Detective has this limitation, xojo sends the event on WM_USER+100 and that isn’t listed in WD.

You’ll need Spy++ from Microsoft.

It comes as part of Visual Studio and you’ll find it in C:\Program Files (x86)\Microsoft Visual Studio\\Community\Common7\Tools when you install it called spyxx.exe (32bit version) or spyxx_amd64.exe (64bit version). You’ll need to run the edition of the build type you have selected in Xojo.

When you select Log Messages, choose the option “Windows of the Same Process” at the bottom and it’ll include all messages from your app if you don’t see any messages double check that you’re running the same 32bit/64bit edition as your app.

I can’t see how it’ll be a compiler issue as you’re still using the same edition and the same compiler but you never know, stranger things have happened.

Failing all that you’ll need to build a test app for them to determine if its been affected by a recent patch at their end.

Thanks - Spy++ it is.

The bad part is that this is REALStudio 2001r3, I very much think they can do nothing. But Xojo is nice, perhaps William (Windows compiler guy) will remember what may cause this.

So… although I know that no timers are firing, a significant part of the interface gets updated via a single-shot timer. I found that minimizing the Window causes that timer to fire. That doesn’t solve the issue, though.

I have a feeling it’s the bug I know of, which is every so often saving files in REALStudio causes a 4 byte corruption in a random file, but almost always the compiler catches it as a syntaz error. You go into the editor and you see the textual corruption, easy fix. Perhaps this was worse. I think it’s a combination code-corruption and compiler-error that is the case. The Mac builds are fine, it’s just the Windows one.

I moved the code over to Windows and ran it Debug on a RS2012 r2.1, same problem. Again, this points to source code corruption. Where that is, dunno yet.

So… I know I compiled a valid copy Sept 23rd. I made a backup on Sept 24th. I’m going to reverse and see if I can turn back the clock to “fix” this. Most of my coding is on a dylib/DLL in C++ that runs off my REALStudio front end.

I would like to hear from anyone else that may have another idea.

It sounds like you’re saving as binary project files? If so, have you tried Arbed? It might be able to detect the corruption. And maybe fix? Don’t know. It can compare binary projects and show the differences.

Good suggestion on Arbed. I’m saving to XML for this very purpose. Te tricky thing about this, though, is that you would think, like every other time, the compiler detects the corruption and fails to compile. Apparently this was sneaky enough to not prevent compilation but just affect Windows builds - and just one aspect of Windows builds. One doesn’t expect just neat and tidy corruption.


Problem solved, I saved the small changes I remember making, took my backup, inserted the changes, and everything is great.

I was really worried because it LOOKED like a compiler error, and since I’m using such an old REAL, I didn’t expect any help. Thanks everyone.