This is probably obvious for most of you, but since I didn’t realize it until now, I will bring it to your attention. This C++ tutorial about templates http://www.cplusplus.com/doc/tutorial/templates.html points out that templates is compiled on demand. Close to the end of the article it states;
“From the point of view of the compiler, templates are not normal functions or classes. They are compiled on demand, meaning that the code of a template function is not compiled until an instantiation with specific template arguments is required. At that moment, when an instantiation is required, the compiler generates a function specifically for those arguments from the template.”
So what you do when you build templates in C++ is utilizing the metaprogramming paradigm in compile time. Now, referring to one of my earlier posts called Metaprogramming, I quote Wikipedia who states;
“Not all metaprogramming involves generative programming. If programs are modifiable at runtime (such as in Lisp, Python, Smalltalk, Ruby, PHP, Perl, and Tcl), then techniques can be used to perform metaprogramming without actually generating source code.”
I realize that the languages spoken of in the Wikipedia may perform other types of runtime metaprogramming, also any or none of these languages may or may not utilize generics. However looking at this text, I figure that metaprogramming is clearly a component in generics, even if it is done in runtime or compile time. One could argue that the programmer should be able to choose if a certain implementation of generics should be evaluated in compile time or runtime.
Finally, would it not be possible to define the functionality of generics if the possibility of generic metaprogramming, compile time or runtime, is available in the given language? If so, would you regard generics as a programming pattern rather than a programming paradigm? Are there more programming paradigms that we could squeeze under the roof of metaprogramming?
PS: I should bring my selfe to compile a generics example in C# and take a look at the resulting IL.
Wednesday, September 19, 2007
Monday, September 17, 2007
The mother of all languages
The last week or so, I have been roaming the internet (especially Wikipedia) for information about alternative programming languages, paradigms and theories about these two. I have no solution what so ever about this. But finally I know how I am going to attack this problem of understanding the magic of programming languages.
When I solve any programming related problem I usually break down the problem in layers of abstraction. In other words, I build many small problem solvers which in turn makes it easy to solve the bigger problem in the end. So I think I need to start looking at the roots, and then work my way from there. I want a language in which I can define any other language implementing any programming paradigms.
I will keep you informed of any progress..
Addition: After writing this article I googled "The mother of all languages". Didn't find anything useful. Went to bed, couldn't sleep. Got up and googled "programming paradigms" and found this article: Language Oriented Programming: The Next Programming Paradigm This is exactly what I'm after right now.
When I solve any programming related problem I usually break down the problem in layers of abstraction. In other words, I build many small problem solvers which in turn makes it easy to solve the bigger problem in the end. So I think I need to start looking at the roots, and then work my way from there. I want a language in which I can define any other language implementing any programming paradigms.
I will keep you informed of any progress..
Addition: After writing this article I googled "The mother of all languages". Didn't find anything useful. Went to bed, couldn't sleep. Got up and googled "programming paradigms" and found this article: Language Oriented Programming: The Next Programming Paradigm This is exactly what I'm after right now.
Metaprogramming
I was sick last week, made me turn the hours around. So another sleepless night brings me back from bed, into my chair in front of the computer. What is haunting me the most right now it the answers to my friend Johans riddles. And I stumble upon a word I didn’t recognize – Metaprogramming. So I use Wikipedia (as you may have noticed) as my major tool to understand all of these words and concepts that I have never seen.
http://en.wikipedia.org/wiki/Metaprogramming - Read it!
I soon discover that Metaprogramming is a fancy word for self modifying code, code generators, translators, macros. You name it, anything that has anything to do with generating new code. So I grasp the concept. I read on anyway because the article is interesting and might shed new exciting light upon the subject, mainly because I’m into code generators and O/R-mapping.
Then I read something that is very intriguing;
“Not all metaprogramming involves generative programming. If programs are modifiable at runtime (such as in Lisp, Python, Smalltalk, Ruby, PHP, Perl, and Tcl), then techniques can be used to perform metaprogramming without actually generating source code.”
I don’t understand this text. What does it mean? It sounds very intriguing, but I cannot grasp the concept. I read it over and over and I finally level with it, and realize that this is what I used to do with macros back in the days of assembler and C++ programming. Only now, the language itself supports generating itself in runtime. Whilst macros are evaluated at compile time or even pre compile. So I read on, the text talks about compilers being metaprogramming tools. Then, the second last sentence hits me hard;
“Having the programming language itself as a first-class data type (as in Lisp) is also very useful.”
Oh my God!
And a whole world of possibilities unravels before my inner vision..
http://en.wikipedia.org/wiki/Metaprogramming - Read it!
I soon discover that Metaprogramming is a fancy word for self modifying code, code generators, translators, macros. You name it, anything that has anything to do with generating new code. So I grasp the concept. I read on anyway because the article is interesting and might shed new exciting light upon the subject, mainly because I’m into code generators and O/R-mapping.
Then I read something that is very intriguing;
“Not all metaprogramming involves generative programming. If programs are modifiable at runtime (such as in Lisp, Python, Smalltalk, Ruby, PHP, Perl, and Tcl), then techniques can be used to perform metaprogramming without actually generating source code.”
I don’t understand this text. What does it mean? It sounds very intriguing, but I cannot grasp the concept. I read it over and over and I finally level with it, and realize that this is what I used to do with macros back in the days of assembler and C++ programming. Only now, the language itself supports generating itself in runtime. Whilst macros are evaluated at compile time or even pre compile. So I read on, the text talks about compilers being metaprogramming tools. Then, the second last sentence hits me hard;
“Having the programming language itself as a first-class data type (as in Lisp) is also very useful.”
Oh my God!
And a whole world of possibilities unravels before my inner vision..
Sunday, September 16, 2007
ScopeGuard for C#
I just found this article by Nicholas Blumhardt at Ubik Systems (http://ubik.com.au/article/named/andreis_scopeguard_for_c). I should let the article talk for itself, but I must say something about it first.
What is it? It’s kind of a generic transaction engine. This means that if you have very important piece of code that must not alter the state of your application if not completed, then you can define steps to roll everything back.
How does it work? Simple as igneous, anonymous functions is stored up in an array as your code runs along. When the code hits an exception, each of the functions is executed in “Last In First Out” (LIFO) order. Everything is implemented in a single class called Guard.
I am fond of code that clearly defines the happy execution path. This solution will mess up the happy path and obscure the original intension of the code. However, this is a simple and creative solution to a tough problem.
Finally, those guys over at Ubic is really bright, you should read all of their articles and check out their projects aswell.
What is it? It’s kind of a generic transaction engine. This means that if you have very important piece of code that must not alter the state of your application if not completed, then you can define steps to roll everything back.
How does it work? Simple as igneous, anonymous functions is stored up in an array as your code runs along. When the code hits an exception, each of the functions is executed in “Last In First Out” (LIFO) order. Everything is implemented in a single class called Guard.
I am fond of code that clearly defines the happy execution path. This solution will mess up the happy path and obscure the original intension of the code. However, this is a simple and creative solution to a tough problem.
Finally, those guys over at Ubic is really bright, you should read all of their articles and check out their projects aswell.
Saturday, September 15, 2007
Stuck with the traditional approach
I wanted to write a blog about programming paradigms. But it end up being a personal story of my life, so I crapped it. Anyway, what I wanted to say is all experiences it good, even bad ones. And therefore it doesn’t hurt to try out new languages, to broaden your perspective. But before choosing a new language to learn you might want to look at these links first:
http://en.wikipedia.org/wiki/Programming_paradigm - talks about programming paradigms. The fact that there was something called programming paradigm was unknown to me until a while ago when I started to investigate different languages.
http://en.wikipedia.org/wiki/Multiparadigm_programming_language - this is the killer. It talks about how most programming languages are multi-paradigm.
Read these Wikipedia articles. They are both interesting and thoughtful. When you have read about them then you would probably want to continue with these:
http://en.wikipedia.org/wiki/Imperative_programming - imperative programming, common in most languages, but you never see “at least two years of experience with imperative programming” in job advertising.
http://en.wikipedia.org/wiki/Object-oriented_programming - object oriented programming, you know this one, and you see it everywhere “at least two years of experience with object oriented programming”.
http://en.wikipedia.org/wiki/Generic_programming - generics, the hot stuff in C# 2.
http://en.wikipedia.org/wiki/Functional_programming - functional programming, the hot stuff in C# 3.
Try to question what is good and what is bad in each paradigm. That is a valuable leasson for you!
http://en.wikipedia.org/wiki/Programming_paradigm - talks about programming paradigms. The fact that there was something called programming paradigm was unknown to me until a while ago when I started to investigate different languages.
http://en.wikipedia.org/wiki/Multiparadigm_programming_language - this is the killer. It talks about how most programming languages are multi-paradigm.
Read these Wikipedia articles. They are both interesting and thoughtful. When you have read about them then you would probably want to continue with these:
http://en.wikipedia.org/wiki/Imperative_programming - imperative programming, common in most languages, but you never see “at least two years of experience with imperative programming” in job advertising.
http://en.wikipedia.org/wiki/Object-oriented_programming - object oriented programming, you know this one, and you see it everywhere “at least two years of experience with object oriented programming”.
http://en.wikipedia.org/wiki/Generic_programming - generics, the hot stuff in C# 2.
http://en.wikipedia.org/wiki/Functional_programming - functional programming, the hot stuff in C# 3.
Try to question what is good and what is bad in each paradigm. That is a valuable leasson for you!
What will the others think?
So in my last post I lightly shared some of my philosophical thoughts about generics. I can't say that I really understand what I’m on about in that post. However there is a lot of stuff that could be done to the most common languages out there. What I like about C#, is the fact that Microsoft continue to develop the language. This encourage the thought that we might have a really good programming language some day.
All of this is interesting, and I am always interested in ways to better my code. New syntax gives me more power and possibly new ways to design and write better code. So I am a coding geek, but I am also a professional. S0 when someone tells me that functional programming will improve my code and make it easier to maintain, then I can agree with that person to a certain level. Now, some of you might think that I am stupid to agree to this only “to a certain level”, but most programmers isn't interested in experimenting with new syntax that they feel uncomfortable with. And they usualy state that the way they've always solved problems work, changing it will only introduce more risk then reducing.
So what will happen when we enter the full blown era of C# 3? Well I will of course take advantage of this in my design. And I will probably write the toughest parts in our projects myself, but what will happen when one of the other programmers must put a lambda expression into a method call that I have written? I think they will question my thinking. It doesn’t matter what I think, they are content with how they solve problems already.
Let’s face it, functional programming and full blown utilization of generics turn object oriented programming on the edge. It’s totally a new way of thinking. And I don’t think that many programmers out there are ready for it, or even interested in getting ready for it.
My final point is that when I act system architect, I also have the competence of my collegues in mind. Not doing so will risk the time frame of the project. But keep in mind that I also have their personal education to think about. There must be balance.
All of this is interesting, and I am always interested in ways to better my code. New syntax gives me more power and possibly new ways to design and write better code. So I am a coding geek, but I am also a professional. S0 when someone tells me that functional programming will improve my code and make it easier to maintain, then I can agree with that person to a certain level. Now, some of you might think that I am stupid to agree to this only “to a certain level”, but most programmers isn't interested in experimenting with new syntax that they feel uncomfortable with. And they usualy state that the way they've always solved problems work, changing it will only introduce more risk then reducing.
So what will happen when we enter the full blown era of C# 3? Well I will of course take advantage of this in my design. And I will probably write the toughest parts in our projects myself, but what will happen when one of the other programmers must put a lambda expression into a method call that I have written? I think they will question my thinking. It doesn’t matter what I think, they are content with how they solve problems already.
Let’s face it, functional programming and full blown utilization of generics turn object oriented programming on the edge. It’s totally a new way of thinking. And I don’t think that many programmers out there are ready for it, or even interested in getting ready for it.
My final point is that when I act system architect, I also have the competence of my collegues in mind. Not doing so will risk the time frame of the project. But keep in mind that I also have their personal education to think about. There must be balance.
Friday, September 14, 2007
Generics C# 2.0
I'm not an experienced programmer when it comes to generics. I thought that I was. However, the more interested I get in programming languages, the more I tend to look at other languages. Now I realize C# 2 is limited.
Disclaimer: Understand that I limit my discussion to C# 2 as reference, I haven’t checked out C# 3 fully just yet, so I will not even bother stating anything about it. Also realize that this particular subject isn't my primary. Johan (blog in Swedish http://hoomla.blogspot.com/), a friend of mine introduced me to the mysterious world of questioning why languages look the way they look. I find myself thinking in other patterns now days, that’s all. So I have some thoughts that I want to put down.
You all know how List<> work, you declare your List<> and give it a type to adopt. Then we have Dictionary<,> where you define two types that you want the class to adopt. Both are good, you can do great stuff with these things. But what if you could declare something like an Array<Tn> where n is a variable number of T’s. Example, I want an Array that holds two strings and a integer, then I would do this Array<string, string, int>. Or if I wanted an Array with one string, one integer and MyType, then I would declare it Array<string, int, MyType>.
As far as I understand, some languages have support for this, it’s called Tuples. F# has Tuples, I haven’t investigated if it is what I think it is just yet. So how would we go about using this generic generics then? What would a foreach look like? I don’t know, could we use foreach or should we need to use more functional programming?
However, generics aren’t limited to arrays or lists. That’s just the most obvious reason to use them. FPSharp is a great example of what you can do with generics (http://sourceforge.net/projects/fpsharp). Credit goes to Johan who find and investigate tons of these things every day.
Disclaimer: Understand that I limit my discussion to C# 2 as reference, I haven’t checked out C# 3 fully just yet, so I will not even bother stating anything about it. Also realize that this particular subject isn't my primary. Johan (blog in Swedish http://hoomla.blogspot.com/), a friend of mine introduced me to the mysterious world of questioning why languages look the way they look. I find myself thinking in other patterns now days, that’s all. So I have some thoughts that I want to put down.
You all know how List<> work, you declare your List<> and give it a type to adopt. Then we have Dictionary<,> where you define two types that you want the class to adopt. Both are good, you can do great stuff with these things. But what if you could declare something like an Array<Tn> where n is a variable number of T’s. Example, I want an Array that holds two strings and a integer, then I would do this Array<string, string, int>. Or if I wanted an Array with one string, one integer and MyType, then I would declare it Array<string, int, MyType>.
As far as I understand, some languages have support for this, it’s called Tuples. F# has Tuples, I haven’t investigated if it is what I think it is just yet. So how would we go about using this generic generics then? What would a foreach look like? I don’t know, could we use foreach or should we need to use more functional programming?
However, generics aren’t limited to arrays or lists. That’s just the most obvious reason to use them. FPSharp is a great example of what you can do with generics (http://sourceforge.net/projects/fpsharp). Credit goes to Johan who find and investigate tons of these things every day.
Monday, October 03, 2005
PocketHAL kick ass
This blog isn’t going to be about CAB-files either.
I ported my code from GAPI to PocketHAL today. I must say that the results surprised me a lot. First off, the code actually runs a bit slower on my hw6515. I don’t know if it’s actually slower, there is some stuff to take into consideration. For example, there is a FPS counter running in realtime, on display. It might take some time to render.
Then I ran it on my h5450, and DAMN! PocketHAL really hits the h5450’s sweet spot! When I was running upon GAPI, I managed to optimize the code about a little. The rasteriser inner loop was optimized using tips from Writing Efficient C for ARM (a thread on PocketMatrix), and I managed to squeeze another 5-6 FPS out of the h5450 (all while the hw6515 was gaining 50 FPS or so, and the Axim x30 another 100 FPS). But when I ported the code over to PocketHAL I suddenly had better results from the h5450 then I had from the hw6515. Damn, was I surprised! The S100 and the x30 however didn’t show any staggering results at all, more or less the same as I got with GAPI. I dare say that my hunch feeling is that it is actually slower on the hw6515, x30 and S100.
I don’t know why it turned out like this. I think that I should investigate some in it, or maybe I’ll just ignore it and live happily with the thoughts of my fine ‘ol h5450 isn’t so bad after all :). I have decided to go on with PocketHAL, because it gives good performance over more machines. I will donate some money tomorrow or so, so that I can have the untagged version.
So what’s up next? I think I will look at the PocketFrog project, it introduces some handy functionality. However after I browsed thru some of the code, I suspect that there are some optimizations left to do (as if I don’t have to optimize my own code first). But still, reading images from disc and other useful stuff would really come handy.
So I suppose I will write about PocketFrog tomorrow.
I ported my code from GAPI to PocketHAL today. I must say that the results surprised me a lot. First off, the code actually runs a bit slower on my hw6515. I don’t know if it’s actually slower, there is some stuff to take into consideration. For example, there is a FPS counter running in realtime, on display. It might take some time to render.
Then I ran it on my h5450, and DAMN! PocketHAL really hits the h5450’s sweet spot! When I was running upon GAPI, I managed to optimize the code about a little. The rasteriser inner loop was optimized using tips from Writing Efficient C for ARM (a thread on PocketMatrix), and I managed to squeeze another 5-6 FPS out of the h5450 (all while the hw6515 was gaining 50 FPS or so, and the Axim x30 another 100 FPS). But when I ported the code over to PocketHAL I suddenly had better results from the h5450 then I had from the hw6515. Damn, was I surprised! The S100 and the x30 however didn’t show any staggering results at all, more or less the same as I got with GAPI. I dare say that my hunch feeling is that it is actually slower on the hw6515, x30 and S100.
I don’t know why it turned out like this. I think that I should investigate some in it, or maybe I’ll just ignore it and live happily with the thoughts of my fine ‘ol h5450 isn’t so bad after all :). I have decided to go on with PocketHAL, because it gives good performance over more machines. I will donate some money tomorrow or so, so that I can have the untagged version.
So what’s up next? I think I will look at the PocketFrog project, it introduces some handy functionality. However after I browsed thru some of the code, I suspect that there are some optimizations left to do (as if I don’t have to optimize my own code first). But still, reading images from disc and other useful stuff would really come handy.
So I suppose I will write about PocketFrog tomorrow.
Sunday, October 02, 2005
3D graphics coding on Pocket PC
3D graphics in your Pocket PC
So I said in my last blog that this blog was going to be about CAB-files huh? Yeah I suppose I did. Anyway, it isn’t going to be about that. Next blog will be about that however.
A year ago I coded a Java Applet on a Apple iBook. Some weeks ago I found that source again and put the demo online Java 3D Applet. And then I decided that I should port that code into C# and make it run on Pocket PC. I had it running in about a couple of hours. Basically all I had to do was correct the syntax. Now I had to run it upon some sort of graphics library. GapiNet sucks really bad, so that wasn’t an alternative. GapiDrawNet however is qute fast, so I used the 30 day demo version to render my whatever my 3D-engine was going to spit in my lap.
I found out that GapiDrawNet didn’t include any good polygon drawers, but only rectangular drawing. I haven’t looked any closer at GapiDraw to see if perhaps there was a polygon drawer in the native lib that just wasn’t mapped into the GapiDrawNet code. So I draw some lines instead, and all was extremely slow. :(
Anyway, I started out on a quest to port my 3D-engine to C++ instead. It was easier said then done. I ended up rewriting the whole code, plus some other code. I also scrapped GapiDraw since it is too expensive for me, and wrote my own graphics lib. Now I have managed to render some cool stuff in real time.
This screen shot is taken from the emulator. I don’t have any mesh reader implemented so I have only tried the cube yet.
Now, let’s do some benchmarking.
HP iPAQ hw6515: Width: 240, Height: 240, FPS: 152
QTek S100: Width: 240, Height: 320, FPS: 110
Axim X30: Width: 240, Height: 320, FPS: 206
HP iPAQ h5450: Width: 240, Height: 320, FPS: 44
Next step would be to optimize it. I think there is a lot that could be done to it. There are a lot of features that I would like to add to the engine as well. Lighting is probably the first thing I will look at. Alpha shading would be nice too. Also I think that I will probably scrap my own GAPI wrapper and go for PocketHAL since it support a lot more features then I will ever bother to put in. Another positive thing about PHAL is that it’s donateware, so even I can afford it :).
When I am satisfied with those things, I think I will go on and write some 2D graphics stuff. I just had to get the 3D out of my system :D.
If you want to get into graphics programming on the Pocket PC then I suggest you check out http://www.pocketmatrix.com/ these guys are sharp.
Oh I forgot, you can download the demo from http://frasse.zapto.org/gouraud.exe, just put it on your Pocket PC (ARM) and run it.
So I said in my last blog that this blog was going to be about CAB-files huh? Yeah I suppose I did. Anyway, it isn’t going to be about that. Next blog will be about that however.
A year ago I coded a Java Applet on a Apple iBook. Some weeks ago I found that source again and put the demo online Java 3D Applet. And then I decided that I should port that code into C# and make it run on Pocket PC. I had it running in about a couple of hours. Basically all I had to do was correct the syntax. Now I had to run it upon some sort of graphics library. GapiNet sucks really bad, so that wasn’t an alternative. GapiDrawNet however is qute fast, so I used the 30 day demo version to render my whatever my 3D-engine was going to spit in my lap.
I found out that GapiDrawNet didn’t include any good polygon drawers, but only rectangular drawing. I haven’t looked any closer at GapiDraw to see if perhaps there was a polygon drawer in the native lib that just wasn’t mapped into the GapiDrawNet code. So I draw some lines instead, and all was extremely slow. :(
Anyway, I started out on a quest to port my 3D-engine to C++ instead. It was easier said then done. I ended up rewriting the whole code, plus some other code. I also scrapped GapiDraw since it is too expensive for me, and wrote my own graphics lib. Now I have managed to render some cool stuff in real time.
This screen shot is taken from the emulator. I don’t have any mesh reader implemented so I have only tried the cube yet.
Now, let’s do some benchmarking.
HP iPAQ hw6515: Width: 240, Height: 240, FPS: 152
QTek S100: Width: 240, Height: 320, FPS: 110
Axim X30: Width: 240, Height: 320, FPS: 206
HP iPAQ h5450: Width: 240, Height: 320, FPS: 44
Next step would be to optimize it. I think there is a lot that could be done to it. There are a lot of features that I would like to add to the engine as well. Lighting is probably the first thing I will look at. Alpha shading would be nice too. Also I think that I will probably scrap my own GAPI wrapper and go for PocketHAL since it support a lot more features then I will ever bother to put in. Another positive thing about PHAL is that it’s donateware, so even I can afford it :).
When I am satisfied with those things, I think I will go on and write some 2D graphics stuff. I just had to get the 3D out of my system :D.
If you want to get into graphics programming on the Pocket PC then I suggest you check out http://www.pocketmatrix.com/ these guys are sharp.
Oh I forgot, you can download the demo from http://frasse.zapto.org/gouraud.exe, just put it on your Pocket PC (ARM) and run it.
Friday, September 30, 2005
Writing a Home Screen plugin
Writing a Home Screen plugin
In my last blog I promised you guys a blog about Home Screen plugin development. Well Jason on Virtueoffice wrote a pretty good Home Screen tutorial for you already, and I feel no need to repeat what he already have written. Check out his series of home screen tutorials Home Screen Plugin Tutorial - Part 1: The Basics.
Now there were many things that Jason just showed the code for, whilst not explaining what the code actually does. So I think that perhaps I could shed some light on those parts that was a little bit hard to understand.
COM
If you don’t know what COM is yet, then you have saved your self loads of headaches. It is true, almost everyone hates COM, but it is here and we have learned to accept it. So what do we do?
We start out by fetching our self a brand new GUID. What is a GUID you may ask? Well GUID is short for Global Unique Identifier. What is that then? It is a ship load of numbers that end up being a unique id. Ok, so we have this unique id stored in our brand new COM DLL, and we ship that DLL to a device and when it is there it will have to be registered in Windows. The registration progress goes something like this. Windows loads your DLL and executes the DllRegisterServer() method that you declared in your code. If you for some reason want to unregister your DLL then Windows would execute DllUnregisterServer() in your code. Basically all these two methods actually do is writing/deleting some information about your DLL in the registry so that Windows has some background information about them.
This is not a bad or unnecessary thing, because your GUID will be written together with the path to the DLL and other interesting stuff. This means that if you for some reason are about to use a COM object in your code, you could just referee to the GUID and let Windows take care of finding it for you. Now, if that was the only smart thing about COM then we might as well just use the good‘ol way, giving the frikkin path and roll with it. But oh no, this is where the magic starts to sparkling and go all wild. Because you would referee to the GUID instead of the path to the DLL, thus making these calls go thru some sort of COM DLL manager in the OS that acts like much like a proxy, the DLL only needs to be loaded once. Now all applications that are using this COM DLL are using the very same copy of the DLL in RAM rather then keeping their own copy of the DLL. This also allows the applications to communicate with each other thru the COM DLL memory space. I think that another intension was to save some RAM too.
Now that you understand that, you could probably muster up the imagination of one thing that gives us a shit load of security holes in Windows. You could also imagine what would happen to the three applications that depend on a certain COM DLL, if it was updated by its developer and the old GUID was kept from the old version for some reason. You are probably right, (let’s take a wild guess) many of these applications would start behaving very strange.
So how do they work? Well a COM DLL implements something called a Class Factory or an implementation of interface IClassFactory to be sure. This is a class that hands out new instances of your main class (in the Jason Home Screen example it would be the PluginBase class), keeps track of how many objects that is out there and other cool stuff that a factory needs to do. Now that we have this factory available, Windows could just go there and ask for another COM Object and our factory would produce it for Windows. Now Windows may ask if it could unload our COM DLL from RAM, then our factory manager could say something like “Oh no, that wouldn’t do! I still have objects out there!” or it could just return FALSE. This entire infrastructure is cool and all, but yes it presents a lot of potential security risks and memory leaks if the COM DLL coder doesn’t do his job well and write a lot of code that is just boring code that have to be written. And that is probably one reason why many coders don’t like ‘em.
Now you see that I haven’t even touched actual code regarding COM and I have written too much about the subject just to cover up some background info for you. I suggest that you sit down with the source from the Home Screen plugin and check it out on your own with this background info fresh on your mind.
The Plugin
Your actual plugin class for the Home Screen need to implement two interfaces, IHomePlugin and IPersistStream.
IHomePlugin gives you four important methods that you need to implement in your class. Initialize(), GetHeight(), GetSelectability() and OnEvent().
IPersistStream gives you four other important methods that you need to implement. IsDirty(), Load(), Save() and GetSizeMax(). Where I think that you will use only Load() and Save().
Now let’s look at the scenario where you have a finished Home Screen plugin and you have added it to your myhome.home.xml file with the <plugin> tag. You go into your SmartPhone settings and chose Home screen and chose your custom XML and you return back to your home screen to see what it looks like. What will happen in your code now?
Could some one explain to me why step 6 to 10 is necessary? I’ve read explanations that it would solve eventual memory leaks that could occur in the initialization process of a plugin, but I can’t figure out the logic in that. Because once the DLL is loaded, it will not be unloaded, so eventual memory leaks will not be released after all. Or is there something in COM architecture that I am missing here?
The OnEvent
The OnEvent() method is executed whenever your plugin needs to do something in particular.
If your plugin is selected and the user presses a direction key, the PE_KEYDOWN message is sent with the OnEvent() method. Now you need to figure out what key was pressed and take action accordingly. If your plugin is selected and the user presses the action key (on most SmartPhone devices it would be the joystick, not in any direction but strait down into the device) you will receive the PE_ACTION message. Whenever your plugin is invalidated you will receive a PE_PAINT. And so it goes on. It’s not that hard to figure out what they all do.
One good thing about the Home Screen plugins, is that they doesn’t suffer from the same update problematics that the Today Screen does. In my MobiDock plugin I use the same code for rendering the Today Screen as the Home Screen. Actually I reuse all code that is not Today Screen API specific in the Home Screen plugin. But the Today Screen flickered, which the Home Screen did not even when I wasn’t using the double buffer technique. I think this is because each plugin is painted on the actual Home Screen window, whilst a Today Screen plugin has it’s own window that is on top of the Today Screen window.
To sum everything up
Once you’ve got code that handles all the COM specific functionality up and running, I think that the Home Screen API is nicer then the Today Screen API, with the IHomePlugin interface and all. But in the end, it’s all ruined by the COM thingy. I don’t know if you’re even supposed to be able to load more the one instance of each plugin. Or if your supposed to be able communicate with your plugin from another process using the COM techniques available? If so I think it’s an atom bomb to kill a bee solution.
Anyway, next blog will probably be about CAB files on your smart devices. How you can write a smart setup.dll that is executed by the CAB installer and other neat stuff.
I started writing this because I couldn’t sleep. Now I think I will drop dead when I reach my bed.
In my last blog I promised you guys a blog about Home Screen plugin development. Well Jason on Virtueoffice wrote a pretty good Home Screen tutorial for you already, and I feel no need to repeat what he already have written. Check out his series of home screen tutorials Home Screen Plugin Tutorial - Part 1: The Basics.
Now there were many things that Jason just showed the code for, whilst not explaining what the code actually does. So I think that perhaps I could shed some light on those parts that was a little bit hard to understand.
COM
If you don’t know what COM is yet, then you have saved your self loads of headaches. It is true, almost everyone hates COM, but it is here and we have learned to accept it. So what do we do?
We start out by fetching our self a brand new GUID. What is a GUID you may ask? Well GUID is short for Global Unique Identifier. What is that then? It is a ship load of numbers that end up being a unique id. Ok, so we have this unique id stored in our brand new COM DLL, and we ship that DLL to a device and when it is there it will have to be registered in Windows. The registration progress goes something like this. Windows loads your DLL and executes the DllRegisterServer() method that you declared in your code. If you for some reason want to unregister your DLL then Windows would execute DllUnregisterServer() in your code. Basically all these two methods actually do is writing/deleting some information about your DLL in the registry so that Windows has some background information about them.
This is not a bad or unnecessary thing, because your GUID will be written together with the path to the DLL and other interesting stuff. This means that if you for some reason are about to use a COM object in your code, you could just referee to the GUID and let Windows take care of finding it for you. Now, if that was the only smart thing about COM then we might as well just use the good‘ol way, giving the frikkin path and roll with it. But oh no, this is where the magic starts to sparkling and go all wild. Because you would referee to the GUID instead of the path to the DLL, thus making these calls go thru some sort of COM DLL manager in the OS that acts like much like a proxy, the DLL only needs to be loaded once. Now all applications that are using this COM DLL are using the very same copy of the DLL in RAM rather then keeping their own copy of the DLL. This also allows the applications to communicate with each other thru the COM DLL memory space. I think that another intension was to save some RAM too.
Now that you understand that, you could probably muster up the imagination of one thing that gives us a shit load of security holes in Windows. You could also imagine what would happen to the three applications that depend on a certain COM DLL, if it was updated by its developer and the old GUID was kept from the old version for some reason. You are probably right, (let’s take a wild guess) many of these applications would start behaving very strange.
So how do they work? Well a COM DLL implements something called a Class Factory or an implementation of interface IClassFactory to be sure. This is a class that hands out new instances of your main class (in the Jason Home Screen example it would be the PluginBase class), keeps track of how many objects that is out there and other cool stuff that a factory needs to do. Now that we have this factory available, Windows could just go there and ask for another COM Object and our factory would produce it for Windows. Now Windows may ask if it could unload our COM DLL from RAM, then our factory manager could say something like “Oh no, that wouldn’t do! I still have objects out there!” or it could just return FALSE. This entire infrastructure is cool and all, but yes it presents a lot of potential security risks and memory leaks if the COM DLL coder doesn’t do his job well and write a lot of code that is just boring code that have to be written. And that is probably one reason why many coders don’t like ‘em.
Now you see that I haven’t even touched actual code regarding COM and I have written too much about the subject just to cover up some background info for you. I suggest that you sit down with the source from the Home Screen plugin and check it out on your own with this background info fresh on your mind.
The Plugin
Your actual plugin class for the Home Screen need to implement two interfaces, IHomePlugin and IPersistStream.
IHomePlugin gives you four important methods that you need to implement in your class. Initialize(), GetHeight(), GetSelectability() and OnEvent().
IPersistStream gives you four other important methods that you need to implement. IsDirty(), Load(), Save() and GetSizeMax(). Where I think that you will use only Load() and Save().
Now let’s look at the scenario where you have a finished Home Screen plugin and you have added it to your myhome.home.xml file with the <plugin> tag. You go into your SmartPhone settings and chose Home screen and chose your custom XML and you return back to your home screen to see what it looks like. What will happen in your code now?
- The home.exe process will read the custom XML, and find your <plugin> tag with the GUID of your COM DLL attached to it. So it will ask Windows for an object of this type.
- Windows will load the DLL (if it wasn’t loaded already) into RAM and initialize the Class Factory in the DLL. Then Windows will ask the newly born factory for a new Object, which Windows hopefully receives and then pass it on to the home.exe process.
- The home.exe will then take the new object and execute the Initialize() method implemented from the IHomePlugin interface, and pass everything that is within the <plugin> and </plugin> tags of your custom myhome.home.xml file.
- Now it’s up to your plugin to parse whatever it needs out of that XML node and store it in local variables.
- The home.exe will call the Save() method that is implemented with the IPersistStream interface, and pass a IStream object with it.
- Your plugin have to store the values of all the variables that it loaded with the Initialize() method on this stream using the IStream interface method Write(). This is a piece of cake. But why would I need to do that you may ask?
- Your plugin object (note the ‘plugin object’ referees to PluginBase class instance only, not the factory or any other code that might be instantiated in the DLL) will be destroyed by the home.exe process.
- The home.exe process will ask Windows for a new object, which Windows will retrieve from the factory of course.
- The home.exe will execute Load() implemented from the IStream interface in the new object and pass another IStream object from which you can read your earlier Written variables.
- Your plugin must read the values that were stored in the Save() method and return them to their rightful home.
- The home.exe process will execute the GetHeight() method and you need to return the height your plugin intends to have on the screen (in pixels).
- The home.exe process will execute the GetSelectability() method and you are supposed to return a TRUE or a FALSE weather your plugin should be selectable or not.
- From now and on the home.exe process OnEvent() method will be called whenever something interesting is happening to your plugin.
Could some one explain to me why step 6 to 10 is necessary? I’ve read explanations that it would solve eventual memory leaks that could occur in the initialization process of a plugin, but I can’t figure out the logic in that. Because once the DLL is loaded, it will not be unloaded, so eventual memory leaks will not be released after all. Or is there something in COM architecture that I am missing here?
The OnEvent
The OnEvent() method is executed whenever your plugin needs to do something in particular.
If your plugin is selected and the user presses a direction key, the PE_KEYDOWN message is sent with the OnEvent() method. Now you need to figure out what key was pressed and take action accordingly. If your plugin is selected and the user presses the action key (on most SmartPhone devices it would be the joystick, not in any direction but strait down into the device) you will receive the PE_ACTION message. Whenever your plugin is invalidated you will receive a PE_PAINT. And so it goes on. It’s not that hard to figure out what they all do.
One good thing about the Home Screen plugins, is that they doesn’t suffer from the same update problematics that the Today Screen does. In my MobiDock plugin I use the same code for rendering the Today Screen as the Home Screen. Actually I reuse all code that is not Today Screen API specific in the Home Screen plugin. But the Today Screen flickered, which the Home Screen did not even when I wasn’t using the double buffer technique. I think this is because each plugin is painted on the actual Home Screen window, whilst a Today Screen plugin has it’s own window that is on top of the Today Screen window.
To sum everything up
Once you’ve got code that handles all the COM specific functionality up and running, I think that the Home Screen API is nicer then the Today Screen API, with the IHomePlugin interface and all. But in the end, it’s all ruined by the COM thingy. I don’t know if you’re even supposed to be able to load more the one instance of each plugin. Or if your supposed to be able communicate with your plugin from another process using the COM techniques available? If so I think it’s an atom bomb to kill a bee solution.
Anyway, next blog will probably be about CAB files on your smart devices. How you can write a smart setup.dll that is executed by the CAB installer and other neat stuff.
I started writing this because I couldn’t sleep. Now I think I will drop dead when I reach my bed.
Thursday, September 29, 2005
Writing a Today Screen plugin for Pocket PC
Writing a Today Screen plugin for Pocket PC
I'm one of two developers working with MobiDock which is a site developed for Windows Mobile devices. Anyway, our latest MobiDock-add-on was a Today Screen plugin for Pocket PC. It sounded as a fun project when I started working on it. It was some time since I last wrote any C++, but I thought "what the heck" (or something similarly ignorant in Swedish).
First I found out the examples on MSDN, which was OK. And later I found out that there were issues that were not covered by the MSDN articles. So I will try and focus on those.
What you do is that you download the example, lemme see if I can find it... .. yeah here it is Today the Pocket PC, Tomorrow the World!. That article gives you all code you need to begin your fine career as a Today Screen Plugin writer (awesome title there). Fine, now you've got it.
DllMain
DllMain() is the entry point for your DLL. It receives two messages, DLL_PROCESS_ATTACH and DLL_PROCESS_DETACH. DO NOT IGNORE THESE! I know that it is perfectly possible to write a Today plugin not even declaring DllMain(), that however is highly NOT the recommended way to do it. DLL_PROCESS_ATTACH is called whenever a process wants to create an instance of our DLL. DLL_PROCESS_DETACH is called whenever the process is finished with it. Hence we should allocate whatever resources or whatever in the ATTACH message and then release those resources whenever the DETACH message is received.
I got this one tip from a site where one guy recommends that you unregistered your window class before you try to register it, or else your plugin would be invisible in some circumstances. He also states that he doesn’t know why this strange behaviour occurs, only that this is a solution to it. Well the bug occurs because of bad coding of course. He should have registered the window class in DllMain when the Attach message was received and then unregistered it in the Detach message and he wouldn’t have to solve it that way. More about pragmatic programming in the next section :D.
InitializeCustomItem
InitializeCustomItem is the second entry point. This one is special for Today items only. This is where we set in motion whatever resources we allocated in the DllMain. So DllMain is executed sending the Attach message first, then the InitializeCustomItem is called.
Why don’t we skip the DllMain and allocate all our resources in InitializeCustomItem and then release whatever resources in WM_TODAYCUSTOM_CLEARCACHE? Well the answer to that is actually whole other topic for code design (I urge all coders to read The Pragmatic Programmer). Let’s just say that it is good practice to keep allocation and deallocation of resources in the same method or at least level in code, it simplifies the search for eventual memory leaks.
WinProc
What will happen whenever we’ve set our window up correctly is that the first Window message that your message handler (WndProc) will receive a WM_TODAYCUSTOM_QUERYREFRESHCACHE message. This gives you a TODAYLISTITEM-pointer in the WPARAM. This struct has a member called cyp which you set to the intended height of your plugin. Now you return TRUE, telling the caller that you actually want to change the size of your plugin (The caller is the parent window, the today screen). Returning FALSE will tell the caller that nothings changed. Now remember that this message will be sent to your plugin every once in a while, and every time you return a TRUE your window will be invalidated, hence it will also receive a WM_PAINT message. This is an unwanted behaviour because it will force your plugin to re-render when it is not needed, and that might cause flickering behaviour or worst case it will slow down the whole machine or at least the today screen.
However, the WM_TODAYCUSTOM_QUERYREFRESHCACHE message is clearly useful. Let’s say that we are writing a today plugin that displays the current battery status. Every once in a while we need to check whatever battery status we’ve got in our machine. The WM_TODAYCUSTOM_QUERYREFRESHCACHE would be the perfect place to retrieve such data from the system and store it in local variables. Now that we have updated our internal variables we would of course want the display to reflect those changes so we could return a TRUE from the WinProc.
If we return a TRUE from the WinProc then we should absolutely check that our cyp were correct first, that it reflected the intended height of our plugin. A TRUE response from the WinProc will also result in an invalidation of the whole window. We might just want to update a small portion of it, perhaps something that displays the percentage in text or a small icon or, whatever. So instead we will create a RECT that holds the coordinates of what we want to update and just do a InvalidateRect() on that portion of our window. And then we return FALSE from the WinProc.
WM_PAINT
This is the message we all have been waiting for :). Basically you do whatever you usually do when you do your GDI Window painting. But there are some things worth putting down in this blog. First you might want your plugin to have transparent background. The above MSDN code was written for Pocket PC 2000 which utilized only solid background, thus doesn’t cover the transparency feature implemented since the Pocket PC 2002 version. How do we do it?
TODAYDRAWWATERMARKINFO dwi;
dwi.hwnd = hWnd;
dwi.hdc = hdc;
dwi.rc.left = ps->rcPaint.left;
dwi.rc.top = ps->rcPaint.top;
dwi.rc.right = ps->rcPaint.right;
dwi.rc.bottom = ps->rcPaint.bottom;
SendMessage(GetParent(hWnd), TODAYM_DRAWWATERMARK, 0, (LPARAM)&dwi);
That’s about it, we send a message to the today window, handing the RECT to be updated and our window handle and our device context (hdc).
The flicker drives me nuts!
Now that you’ve got your plugin up and running you may notice that it flickers each time you make a move on the today screen, and I do not mean only when your own plugin got focus but also when you step thru the other today items. How do we solve this? The only solution I ever came up with was to actually use an off screen DC.
How do we get an off screen DC you may ask? There is something called a Memory DC, they’re quite easy to use. What you do basically is just CreateCompatibleDC() and you pass on your current DC (the hdc you get when you BeginPaint()). This gives you a compatible device context, but it isnt associated with a bitmap that can handle more then black and white (which I find strange). So you’ve gotta create one your selfe. That is quite simple too, just CreateCompatibleBitmap(), pass on the hdc and the size of your window in a RECT and you have a nice bitmap. Then you just associate the new bitmap with your DC with SelectObject(). Here is some code to help you out.
HDC hdcOffscreen = CreateCompatibleDC(hdc);
HBITMAP hbOffscreen = CreateCompatibleBitmap(hdc,
windowSize.right - windowSize.left,
windowSize.bottom - windowSize.top);
HBITMAP hbOffscreen_Old = (HBITMAP) SelectObject(hdcOffscreen, hbOffscreen);
Now, promis me that you release theise resources when you are finnished with em =)
SelectObject(hdcOffscreen, hbOffscreen_Old);
DeleteObject(hbOffscreen);
DeleteDC(hdcOffscreen);
I suggest that you create the offscreen resources only once, and then you reuse it for all your WM_PAINT messages. This speeds up the painting a lot. Remember, if you do that, then you also must reinitialize them whenever you change the size of your plugin window. Also you must remember to release the resources whenever your plugin is unloaded, you can do that when the WM_TODAYCUSTOM_CLEARCACHE message arrives. I went as far as creating a DC of the background as well, it’s not necessary, it takes up some extra memory but results in a faster WM_PAINT.
I have probably forgotten stuff that I was intending to include. Yeah, there is one more thing that I use extensively. It’s quite a hassle to debug your today screen item. So I created a small app that updates the “Enabled” registry value for my plugin, simply setting it to 0 if it was 1 and the other way around. Then I do a:
SendMessage(HWND_BROADCAST, WM_WININICHANGE, 0xF2, 0)
This message will force the Today screen to update it self, hence loading/unloading your plugin. Now if you keep that “toggle”-application as a part of your solution and set it as the “Startup project”, your plugin will load/unload whenever you press F5.
Next blog will probably be about Home screen plugins :D
I'm one of two developers working with MobiDock which is a site developed for Windows Mobile devices. Anyway, our latest MobiDock-add-on was a Today Screen plugin for Pocket PC. It sounded as a fun project when I started working on it. It was some time since I last wrote any C++, but I thought "what the heck" (or something similarly ignorant in Swedish).
First I found out the examples on MSDN, which was OK. And later I found out that there were issues that were not covered by the MSDN articles. So I will try and focus on those.
What you do is that you download the example, lemme see if I can find it... .. yeah here it is Today the Pocket PC, Tomorrow the World!. That article gives you all code you need to begin your fine career as a Today Screen Plugin writer (awesome title there). Fine, now you've got it.
DllMain
DllMain() is the entry point for your DLL. It receives two messages, DLL_PROCESS_ATTACH and DLL_PROCESS_DETACH. DO NOT IGNORE THESE! I know that it is perfectly possible to write a Today plugin not even declaring DllMain(), that however is highly NOT the recommended way to do it. DLL_PROCESS_ATTACH is called whenever a process wants to create an instance of our DLL. DLL_PROCESS_DETACH is called whenever the process is finished with it. Hence we should allocate whatever resources or whatever in the ATTACH message and then release those resources whenever the DETACH message is received.
I got this one tip from a site where one guy recommends that you unregistered your window class before you try to register it, or else your plugin would be invisible in some circumstances. He also states that he doesn’t know why this strange behaviour occurs, only that this is a solution to it. Well the bug occurs because of bad coding of course. He should have registered the window class in DllMain when the Attach message was received and then unregistered it in the Detach message and he wouldn’t have to solve it that way. More about pragmatic programming in the next section :D.
InitializeCustomItem
InitializeCustomItem is the second entry point. This one is special for Today items only. This is where we set in motion whatever resources we allocated in the DllMain. So DllMain is executed sending the Attach message first, then the InitializeCustomItem is called.
Why don’t we skip the DllMain and allocate all our resources in InitializeCustomItem and then release whatever resources in WM_TODAYCUSTOM_CLEARCACHE? Well the answer to that is actually whole other topic for code design (I urge all coders to read The Pragmatic Programmer). Let’s just say that it is good practice to keep allocation and deallocation of resources in the same method or at least level in code, it simplifies the search for eventual memory leaks.
WinProc
What will happen whenever we’ve set our window up correctly is that the first Window message that your message handler (WndProc) will receive a WM_TODAYCUSTOM_QUERYREFRESHCACHE message. This gives you a TODAYLISTITEM-pointer in the WPARAM. This struct has a member called cyp which you set to the intended height of your plugin. Now you return TRUE, telling the caller that you actually want to change the size of your plugin (The caller is the parent window, the today screen). Returning FALSE will tell the caller that nothings changed. Now remember that this message will be sent to your plugin every once in a while, and every time you return a TRUE your window will be invalidated, hence it will also receive a WM_PAINT message. This is an unwanted behaviour because it will force your plugin to re-render when it is not needed, and that might cause flickering behaviour or worst case it will slow down the whole machine or at least the today screen.
However, the WM_TODAYCUSTOM_QUERYREFRESHCACHE message is clearly useful. Let’s say that we are writing a today plugin that displays the current battery status. Every once in a while we need to check whatever battery status we’ve got in our machine. The WM_TODAYCUSTOM_QUERYREFRESHCACHE would be the perfect place to retrieve such data from the system and store it in local variables. Now that we have updated our internal variables we would of course want the display to reflect those changes so we could return a TRUE from the WinProc.
If we return a TRUE from the WinProc then we should absolutely check that our cyp were correct first, that it reflected the intended height of our plugin. A TRUE response from the WinProc will also result in an invalidation of the whole window. We might just want to update a small portion of it, perhaps something that displays the percentage in text or a small icon or, whatever. So instead we will create a RECT that holds the coordinates of what we want to update and just do a InvalidateRect() on that portion of our window. And then we return FALSE from the WinProc.
WM_PAINT
This is the message we all have been waiting for :). Basically you do whatever you usually do when you do your GDI Window painting. But there are some things worth putting down in this blog. First you might want your plugin to have transparent background. The above MSDN code was written for Pocket PC 2000 which utilized only solid background, thus doesn’t cover the transparency feature implemented since the Pocket PC 2002 version. How do we do it?
TODAYDRAWWATERMARKINFO dwi;
dwi.hwnd = hWnd;
dwi.hdc = hdc;
dwi.rc.left = ps->rcPaint.left;
dwi.rc.top = ps->rcPaint.top;
dwi.rc.right = ps->rcPaint.right;
dwi.rc.bottom = ps->rcPaint.bottom;
SendMessage(GetParent(hWnd), TODAYM_DRAWWATERMARK, 0, (LPARAM)&dwi);
That’s about it, we send a message to the today window, handing the RECT to be updated and our window handle and our device context (hdc).
The flicker drives me nuts!
Now that you’ve got your plugin up and running you may notice that it flickers each time you make a move on the today screen, and I do not mean only when your own plugin got focus but also when you step thru the other today items. How do we solve this? The only solution I ever came up with was to actually use an off screen DC.
How do we get an off screen DC you may ask? There is something called a Memory DC, they’re quite easy to use. What you do basically is just CreateCompatibleDC() and you pass on your current DC (the hdc you get when you BeginPaint()). This gives you a compatible device context, but it isnt associated with a bitmap that can handle more then black and white (which I find strange). So you’ve gotta create one your selfe. That is quite simple too, just CreateCompatibleBitmap(), pass on the hdc and the size of your window in a RECT and you have a nice bitmap. Then you just associate the new bitmap with your DC with SelectObject(). Here is some code to help you out.
HDC hdcOffscreen = CreateCompatibleDC(hdc);
HBITMAP hbOffscreen = CreateCompatibleBitmap(hdc,
windowSize.right - windowSize.left,
windowSize.bottom - windowSize.top);
HBITMAP hbOffscreen_Old = (HBITMAP) SelectObject(hdcOffscreen, hbOffscreen);
Now, promis me that you release theise resources when you are finnished with em =)
SelectObject(hdcOffscreen, hbOffscreen_Old);
DeleteObject(hbOffscreen);
DeleteDC(hdcOffscreen);
I suggest that you create the offscreen resources only once, and then you reuse it for all your WM_PAINT messages. This speeds up the painting a lot. Remember, if you do that, then you also must reinitialize them whenever you change the size of your plugin window. Also you must remember to release the resources whenever your plugin is unloaded, you can do that when the WM_TODAYCUSTOM_CLEARCACHE message arrives. I went as far as creating a DC of the background as well, it’s not necessary, it takes up some extra memory but results in a faster WM_PAINT.
I have probably forgotten stuff that I was intending to include. Yeah, there is one more thing that I use extensively. It’s quite a hassle to debug your today screen item. So I created a small app that updates the “Enabled” registry value for my plugin, simply setting it to 0 if it was 1 and the other way around. Then I do a:
SendMessage(HWND_BROADCAST, WM_WININICHANGE, 0xF2, 0)
This message will force the Today screen to update it self, hence loading/unloading your plugin. Now if you keep that “toggle”-application as a part of your solution and set it as the “Startup project”, your plugin will load/unload whenever you press F5.
Next blog will probably be about Home screen plugins :D
Subscribe to:
Posts (Atom)