ASM Community

I just posted a simple demo of how to do this here.

http://www.masmforum.com/simple/index.php?topic=2445.new#new

It should be easy enoug to adapt to RadAsm format.

Two things, tests will show that the Sleep() API yields to other running threads and set to any value above zero it also does not resume until the millisecond duration has been reached. There are various ways to animate text but they are all a lot more complicated than rotating text. Preferred would be looped BitBlt and if you need it to be asynchronous, you would place the code in a seperate thread.

The virtue of the example is that it is simple and reliable.

Putting it in a seperate thread is probably simpler but I suggest the user will determine what he needs.

This is fine but it has two problems, when you set a timer, it asynchronously runs from a thread and in this world you get nothing for nothing. By calling the timer from the main thread, you pause the operation of the application every 100 milliseconds which will make a real mess of any other processing that the application is performing. A seperate thread solves tis problem is continuous asynchronous action is required. The task switching between threads is far finer and more uniform than a 100 MS granularity of a timer action.

The other factor is you should shut down a timer when you have finished,

        invoke KillTimer,hWin,IDnum

Leaving a timer running when its not needed is a resource waste. It may not matter in a small demo that exits quickly but its poor application design.

Regards,

hutch at movsd dot com

Application design is in fact a different matter to writing a small easy to read demo on how to perform a task as simple as rotating a caption on a window. As usual when you write a small demo, you leave it up to the person who may have a use for it to apply it in whatever way they like. As you chose to introduce the application specific considerations, I have simply pointed out the failure to be exclusive that you suggestion requires.

A task of this type is almost exclusively a novelty that runs for a second or so and as such its no big deal in terms of interface restrictions.

Now as you have bothered to dictate yet another requirement in application design when it comes to handling processor intensive tasks, the user has many options about how they will do this, a simple one is to set the cursor to an hourglass so the end user knows something is happening, they can farm it out to a DLL, they can shove it into a seperate thread if it will be of duration that prevents something ese from being done but this again assumes a multithread application when many applcations are not.

The KISS principle is the one to apply here, the original demo was simple enough to understand and how it is applied in an application is the exclusive domain of the application designer.

For the true addict, I could not resist optimising the algo that does the character rotation. It is at the same link as above.

Regards,

hutch at movsd dot com

I'm not dictating anything, just telling what the de facto standard is.

Handling heavy computations in the same thread that runs your messagepump = bad. Simple as that. Either you have to break the computation into blocks, which can make algorithm design complex, or your application will "block" until the computation is done. This is what gives you those ugly "unpainted windows". Might be okay for a task that takes a second on a pentium2, but not for something that takes several seconds on a P4 or AMD64.

Farm it out to a DLL is independent of whether you do a background thread or process in the messagepump thread.

It all depends on what end-user experience you want to give, and what kind of processing you're doing. Farming out heavy calculations to worker threads is the de-facto standard, simply because it works pretty well.

We differ to this extent, I am more than happy to leave application design to the designer witout inflicting anything on them, it appears you are not from what you say. When I write a demo, its a demo, not a treatise in application design theory and it is as neutral as possible. Proof of the approach was your willingness to plaigarise parts of te demo and set a timer to run it. A perfectly good derivation that was not inflicted on you by the demo but by no means the only approach.

It will work perfectly well in a seperate thread and it works perfectly well without either, the difference between a neutral demo and your attempt to inflict a viewpoint over everyone who may write an application. I will leave you to resolve your dilemma as the guy who asked the question is happy with the results. If you really desperately ned to persist, it can be taken up elsewhere wher the noise will not bother anyone.

Regards,

hutch at movsd dot com

I wonder what you have to prove here, I posted a demo for a member which he seems to be happy enough with and you have subsequently produced a version that used the algorithm in the demo which demonstrated how to set a timer to control the speed of the scrolling. (apart from the mistake in the code where you did not free the timer)

It is the attempt to impose some form of architecture that has brought the comments as the demo I posted was architecture free in its operation and could be used in various ways.

The mistake in you code was not an improvement but a mistake. If you take on a crusade to be the editor of other peoples work, at least get it right.

Regards,

hutch at movsd dot com

Another small oversight of mine, thanks for pointing out - the window creation code was a quick copy-paste from another program, which sets the cursor later, and thus doesn't have wndClass.hCursor set.