how would u add scrolling caption text useing radasm.Any help would be greatly
appreciated :)
appreciated :)
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.
http://www.masmforum.com/simple/index.php?topic=2445.new#new
It should be easy enoug to adapt to RadAsm format.
Not the best way to do this - the application will block until the scrolling is done. Better to use a periodic timer instead.
If you want smoother scrolling, you'll have to paint the Non-Client area (ie, title bar) of the application yourself - this takes more code.
If you want smoother scrolling, you'll have to paint the Non-Client area (ie, title bar) of the application yourself - this takes more code.
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.
The virtue of the example is that it is simple and reliable.
What I meant by "blocking" is that your application will not be responsive while it scrolls. Ie, not possible to click the buttons etc. This is bad, and SetTimer + WM_TIMER processing is simple.
Putting it in a seperate thread is probably simpler but I suggest the user will determine what he needs.
Here's an example of doing it properly, with WM_TIMER. Concentrate on the code in WM_CREATE and WM_TIMER.
Using a thread is IMHO a waste of system resource - threads are relatively cheap, but they're not free.
Using a thread is IMHO a waste of system resource - threads are relatively cheap, but they're not free.
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,
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
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
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.
Well, you have things a bit backwards here; normal program design is to let the main thread handle your messagepump and do very little processing - any kind of heavy processing should be farmed out to worked threads. This way you keep the GUI responsive. Something as simple as rotating the titlebar every 100ms isn't exactly processing heavy, and is a good example of something you would use a timer for.
If pixel-level scrolling is required (which also implies a bunch of other work, like nonclient area repaint handling), a separate thread is probably a good idea, since SetTimer latency and resolution isn't the best.
But remember: threads are a relatively expensive resource, and context switches is not your friend. Sleep does help here, though. I guess it might be worthwhile looking at how SetTimer timers are implemented... but this is pretty nitpickerish.
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.
Indeed, this is an oversight from my side. Thanks for pointing it out. You should always free resources, close handles, etc. when you're done with them.
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
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
cheers for takeing the time to help me out hutch/f0dder much appreciated :)
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.
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.
f0dder:
"What I meant by "blocking" is that your application will not be responsive while it scrolls. Ie, not possible to click the buttons etc."
Not TRUE.
Click several (or more) times (quickly-quickly!) Scroll-button, then Cancel-button,? -? application will be ve-e-ery responsive :-)
"What I meant by "blocking" is that your application will not be responsive while it scrolls. Ie, not possible to click the buttons etc."
Not TRUE.
Click several (or more) times (quickly-quickly!) Scroll-button, then Cancel-button,? -? application will be ve-e-ery responsive :-)
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
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
Whatever.
If you can't handle people improving on your code without taking it as a personal insult, perhaps you shouldn't post on public forums.
If you can't handle people improving on your code without taking it as a personal insult, perhaps you shouldn't post on public forums.
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
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
f0dder is right here.
For hutch example, after I press scroll then I tried to move the window, I experience temporary "lag". Furthermore, after I moved the dialog, the caption text is no longer rotating.
f0dder, in your example, I was wondering why is there an hourglass right after I opened the exe.
For hutch example, after I press scroll then I tried to move the window, I experience temporary "lag". Furthermore, after I moved the dialog, the caption text is no longer rotating.
f0dder, in your example, I was wondering why is there an hourglass right after I opened the exe.
f0dder, in your example, I was wondering why is there an hourglass right after I opened the exe.
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.
Victor,
You are confusing demonstration and application, a demonstration shows HOW its done, a application shows WHERE its done. I don't presume in this context to tell someone where they should apply and idea as application design is a matter for the designer and the range is broad. f0dders plaigarisation showed the demonstration in one application only, that of a set system timer but its not the only way and there is no reason to think its the exclusive or best way. It is in fact presumptuous for anyone to assume they are in a position to dictate to anyone else what they application design should be.
Regards,
hutch at movsd dot com
You are confusing demonstration and application, a demonstration shows HOW its done, a application shows WHERE its done. I don't presume in this context to tell someone where they should apply and idea as application design is a matter for the designer and the range is broad. f0dders plaigarisation showed the demonstration in one application only, that of a set system timer but its not the only way and there is no reason to think its the exclusive or best way. It is in fact presumptuous for anyone to assume they are in a position to dictate to anyone else what they application design should be.
Regards,
hutch at movsd dot com