The compiler FrontEnd is now finished!

Hello again! As I promised last time, I have two big announcements to make. Even though summer has been warm and beautiful, I’ve been working very hard on CoolBasic compiler for the past few weeks. We’re talking about something like 8 hours aday on average, but there were also a few of those days during which I coded 11 hours pretty much non-stop. And it’s been great! Even though most of the work has been nothing but bug fixes, my motivation has all but diminished. Some people might think otherwise, but I actually get encouraged by intriguing bugs that take 24 hours to track down because it’s very rewarding to ultimately fix those.

I don’t normally mention about bugs I’ve found and fixed, but be it exception this time: I had a medium-sized architectural issue regarding method invocation and how the reference is passed to them. Static methods and structure methods add an extra twist. The original implementation had fixed stack position for the reference – which ultimately proved to not work out for complex dot notations that involve static members in the middle. I fixed the problem by re-writing the part that is responsible for recognizing valid references and injecting them into the final code. References are now always at the same relative location they appear in the original statement. Even static methods now have them although those don’t necessarily point to anything. Long and complex dot notation paths in general have been giving me quite a lot of work recently.

The first announcement
I’m proud to announce that I have now finished the Intermediate Language (later referred to as “IL”) entirely. This effectively concludes Pass#2 and thus the compiler FrontEnd is now considered “finished”. It’s been of a long road, and reaching this major milestone is a great relief to me. What this means in terms of progress? The IL still needs yet another transformation, but this time it’ll be final. So basically there’s just one process to make for the compiler, and then I can start working on the runtime. Also, it’s July already, and I think the devTeam won’t be assembled this summer but in autumn perhaps. There just is so much work to do, sorry. I’m about a month late of the original schedule I had. But I’d say it’s normal because in program of this nature surprises tend to emerge. Some of which force medium-to-large re-writes of existing code. Modifications always affect somewhere else and thus extensive testing needs to be done after architectural changes – be it minor or major. Thankfully, I didn’t have to implement major changes to anything (atleast not just yet).

I spent 5 days (there were quite many bug discoveries and fixes involved) to write an extensive array of Unit Tests. A Unit Test is basically a standalone fragment of code that responds to input and output; they are used to test program functionality isolated from the big picture, and each test runs in its own sandbox. These small programs I wrote, test all CoolBasic programming language features. After compilation I examined the emitted IL in detail and ensured that everything went well and that the IL was correct. As a result of this process, I gathered interesting data and statistics I’d like to share with you. I think the numbers speak for themselves:

Test Program:

– Code size: 2547 lines in 7 files, 62 kb in total
– Composition: natural mix of comments, declarations and executing code. All language features
– Symbol table size: 1150 identifiers
– Emitted IL: 7410 lines

Testing Platform:

– HP HDX18-1000EO (Laptop)
– T9400 processor
– 4GB memory
– Windows Vista (64-bit)

Results:

– Number of compilations: 20
– Average compile time: 105 milliseconds
– Fastest compile time: 97 milliseconds

That’s pretty fast compilation considering the complexity of the process. Overall I’m happy with the outcome and that “pressure test”. I’ll be using the same gigantic Unit Test program to validate everything when any new feature gets added later on.

The second announcement
Now that the pressure is mostly gone, there’s something completely different I need to do: I still haven’t finished my thesis, so I’m technically still a student. That’s something I’ll soon need to take care of as the official time limit of graduation is closing to its end (and I don’t wish to extend it). As some of you may know, I already work as professional software engineer, so that’s taken some time and focus off the studies. The only thing remaining (and the only reason I’m still in their register as “pending graduation”) is the unfinished thesis. So I’ll take a few weeks off CoolBasic, and finish up my studies in Bachelor of Business Administration in Information Technology. Graduation and receival of the official “shiny paper” will also be a great relief, and after that I can fully focus on CoolBasic once again. I will start the thesis from a blank table very soon. During this time, however, I will be watching the forums, and am available via IRC (nothing new there). My four-week summer holiday is starting on 20th July so I have lots of resources to use on the thesis (although I don’t wish to spend all the summer indoors). I will also be participating in Assembly Summer 2009 this year!

Some random thoughts
I reviewed CoolBasic V3 manual. After careful consideration, I came to conclusion that the black theme is unfitting to such material that is to become the primary textual source of information for Coolbasic V3. Although silver text is still very readable on black background, you can actually read dark text on white background longer without the eyes growing tired. I’ve taken a little more MSDN-like approach although I plan to enhance the visual look and feel.

It’d be cool to allow the online manual to be somewhat interactive and more dynamic. Features such as User Comments, Version History, Multilinguality, and linking to outside sources as well as flexible Maintainability will basically require a database. Thus, online version of the manual is best to separate from offline version. I’d still like to use XSLT for the offline manual, but then the end users couldn’t use Firefox to view it – or otherwise I’d have to make the manual very dull looking basically ignoring text styling within paragraphs. So there’s still some open questions to the offline version, but database approach for the online manual certainly looks quite promising. Either way, it’s always possible to generate the offline manual directly from the database. Database design, however, will be a challenge!

Enjoy the summer, folks!

Compile time error messages

It’s been two and a half weeks since the last entry. It may seem a long time without any updates, but I’ve been working very hard on Pass#2 during this whole time. I finally managed to establish the architecture for data type resolving and name resolution. I just didn’t want to express any thoughts on this highly experimental phase until the solution that actually works on all test cases, has been found. That being said, I’ve spent the last few days on small improvements and bug fixing. Also, this is a good spot to clean up the code and fine-tune the work done so far until I get started with the next big thing (which I won’t elaborate at this point). One thing that needs improving and what has been haunting me for some time now, is the way the compiler expresses compile time errors to the user. The coding has been so hectic from the start that even though the compiler is able to express all the needed errors, some rephrasing is surely needed. Especially for Pass#1 which features a lot of syntax checks, and thus a lot of similarly formatted error messages.

Current V3 compiler error messages
For reference, compilation stops to the first error occurred – to prevent further (possibly misleading) errors from a chain-reaction the first error might have caused. This is identical to how current CoolBasic and many other Basic language compilers report errors. If you have programmed in C and the related languages, you might be familiar with the error flood you get when you try to build a project that had maybe just few small mistakes in the source code. In most cases, the tail of that list consisted of completely mysterious errors, and only because of the preceding errors caused flawed compiling process to proceed until the compiler got too confused to be able to continue. Luckily, compilers have become more intelligent regarding this matter, and for example, Visual Studio is able to construct a list with only the essential errors in it. CoolBasic V3, however, will continue to terminate the entire compilation on first error because of safety and stability. The sooner you get back to fixing it, the better.

Back to the current V3 implementation. To save time, errors are returned as strings when they occurr. I didn’t want to gather the absolute list of Pass#1 errors beforehand because it would have changed anyways. This was fully intended at that point in development. However, now that Pass#1 is essentially finished, I know all the errors that can occurr within it. And there’s now the need of rephrasing which means I would have to Find & Replace them all. Instead, it’s better to standardize the messages by binding them to constants; rephrasing them would require the change to be made to one place only. This need was also foreseen, but now it’s time to implement it. I would have changed the error message generation anyway, but this is also a great opportunity to think over better ways to express errors in terms of how they are phrased; Currently there exists a few vague messages that don’t provide enough information. For example, what does “Statement out of context” tell to the programmer?

The ideal error message
A good error message is uniformal, informative and precise. It should also provide a hint on how to correct the error. That way the programmer doesn’t have to visit the manual or spend time to understand what the error could mean in that particular case – which improves productivity and overall relish. However, being able to tell the error line, code module, the cause and the possible error code for further reference, is not enough. What if you had separarate statements written on the same line (separated with : of course), and you got an error saying “Error at line bla bla in code module bla bla: This statement cannot appear here.” More unnecessary time trying to figure out which statement caused the error. From my point of view it wouldn’t be too much of a work to bother adding this information to the error message, but omitting it would surely add up when hundreds of end users write programs in CoolBasic every day. Picture this: “Declaration context of ‘Const’ is invalid.” Sounds better? Sure, but something is still missing.

Normally I would add a hint on how to correct this error by specifying where constants are allowed or where they cannot appear. In this particular case it’s not that simple, because even though constants can appear within procedures and blocks, they can’t appear within Property or Select statement bodies. Rephrasing this error to cover exact definition where a constant can be declared would result in too complicated error message. Uniformality excludes me from listing the legal declaration contexts as well because their exact contents can vary depending on the statement. Compromises do happen.

Precise error messages also tell meta information about the error. For example, a vague error message like “Identifier is already defined.” doesn’t really tell which identifier is causing the conflict. A better version could be “‘myVariable’ is already declared in its context”, but it can be improved even further, providing more narrowing information: “Variable ‘myVariable’ is already declared in this Class.” – or even by providing the full declaration information, including the data type definition.

Whereas “precise” refers to “contextual detail”, informative errors specify moreover what’s syntactically or semantically wrong. For example, instead of telling “Syntax error. Invalid statement.” you could specify “End of statement expected.”

Detailed error messages tend to increase their amount. That generates variance which easily gets out of hand. Thus, even though you have practically different error messages for telling how different kinds of identifiers conflict in context, or what token statements expect next, they should follow the same basic formatting. This will not only result in impression of quality to the end user, but also makes the developer’s life easier in the future. Uniformality also emerges within the error codes. Even though variables and constants generate slightly different error messages when, say, their data type could not be resolved, they still share the same error code because the error occurred from the same cause. In other words: Error codes are not tied to the actual (unique) description. Something I need to keep in mind…

Showing the error to the user
The current CoolBasic version shows errors inside of a modal window with the code and description in it. Because of its modal nature, you must close the window in order to edit your code. And not only that, you can’t do anything while the windows is there so you *need* to close it. Does anyone else sometimes forget what the actual error message was, while you’re thinking and fixing? Well, I do, and it’s irritating when it happens because I will then probably compile it again to see it. Also, I don’t want to hear the Windows’ exclamation sound every time the compilation fails. In addition, there’s a known issue of Scintilla sometimes invalidating its rendering area when a modal window pops up basically making the source code invisible for quick inspection while the error window is present. So I’m experimenting with an idea to leave the latest error message visible to the bottom section of the editor, in a similar way than Visual Studio does. Also, when you click on that section, you could open the manual page for more details. You could even filter that section to show full error history or the latest error only. The error message should also be easy-to-read meaning that the error module and line number should appear in, say, inside their own respective columns.

The principle is that errors should be silent, but noticeable. And they should not create any unnecessary stir or require actions from the user.

Localize the compiler too?
I have mentioned several times that CoolBasic V3 will be fully localized into both english and finnish. This includes manual, website, forums, editor, tools, examples, tutorials and all of the content in general. There has been one hesitation to the rule, however. Normally compilers don’t get localized. It’s just the way it is, and nobody really questions it. Due to absence of real life examples and “significant” products pioneering this concept (To be honest, I don’t know about Visual Studio. I’m too lazy to check it out, but I haven’t heard about such thing), and combined with the amount of the required maintenance or the infrastructural problems within the compiler’s architecture, the idea hasn’t really catched on. Parts of the error messages would be in english anyway because common base class libraries are mostly coded in english, thus their identifier names mix to the localized language, making it look funny.

With all this rephrasing going on, it’s possible for me to build support for both english and finnish error messages. And I have decided to give it a try. You can always disable it, right? However, I will probably use english as the default compiler language even for localized CoolBasic unless separately changed from the editor’s settings.

The changes brought up in this blog entry will keep me busy for a few days…

CoolBasic websites now and in the past

The new coolbasic.com website went online yesterday. As I mentioned in the previous blog entry, the old placeholder webpage needed to be replaced, because it wasn’t designed to last as long as it now seems it’ll take until launch of CoolBasic V3. It took me one day to build from scratch, but overall there’s much more effort into it. In addition to creation of the CSS-stylesheet and the HTML layout, there’s now a nice feature on the main page that lists recent forum posts and blog entries. Those listings required some manual SQL-queries for two databases on the web server.

I made some archaeological digging, and managed to find all previous websites of CoolBasic ever created (this is fun to watch). Let’s take a tour, beginning from the oldest:

Gigabot original Website, 2003

Gigabot original Website, 2003

First of all, those of you who are familiar with the history of CoolBasic, know that it all began off an idea of making a “programming game”. The game idea is simple – players would need to script an A.I for two bots. These bots would then fight each other, in an arena, and using an array of provided weapons like laser cannons and missiles. During the actual match, the players cannot affect how it goes. The bots simply rely on their A.I scripts until the other gets destroyed. The screenshot above is the original Gigabot homepage (2003). The game never finished (though I’ve thought about re-opening the project some day), but instead it evolved into something we know today as CoolBasic!

The very first website, 2004

The very first website, 2004

The first ever (official) CoolBasic website looked like that. Yep, it’s awful, and it’s from 2004 (Beta 1.0 release3). My www design skills clearly weren’t too good back then 🙂

The first 'real' website

The first 'real' website

Sadly, I couldn’t find this website anywhere. However, forum member Jare managed to find it from the Web Archives. I think it dates back to the late of 2004. It resided on a MBnet server which is a hosting service for a Finnish computing magazine, MikroBitti’s, subscribers. The current version was Beta5 (2nd re-write of the 1st generation).

Website for the current version (2nd generation), 2004/2005

Website for the current version (2nd generation), 2004/2005


The english website, 2005

The english website, 2005

Then there was the famous Blitz battle which lead to complete re-write of CoolBasic, introducing Beta 10 -series and the Object System. Also known as the current version, the 2nd generation. At this point, I registered domain coolbasic.com, and factored a new website seen in the image above. The files date back to 2004-2005. At this point, CoolBasic also got some (unwanted) international attention which lead me to build a fast partial english localization of the manual and the website. The english support never got finished because of my famous take off, but proper localizatoin is something we’ll definately improve for CoolBasic V3.

The temporary placeholder, 2008

The temporary placeholder, 2008

If you haven’t yet read the previous blog entry, I strongly recommend to do so now.

When I made the come-back, CoolBasic V3 development was established (mainly because I realized how awfully outdated the Beta 10 was). The website was also totally out-of-standards, so I had to get rid of it as fast as possible. CoolBasic websites in general follow medium saturated colour theme. This “placeholder” was not an exception, but due to my mindset of “insignificancy” at that time, the technical aspect wasn’t taken care of in such quality I normally would have done.

The better placeholder, 2009

The better placeholder, 2009

This brings us here, the new “placeholder” website. I made an intrepid decision, and used black background this time, as opposed to pretty much any of the previous websites. A good website uses a palette of 3-5 colours to form its theme and feel. I picked yellowish orange and neutral blue that resembles the gutter bar of the current CoolBasic code editor. The orange is great for emphasizing text content, and blue would style all other elements that are not normal text, such as headers and links. The most difficult part was picking the correct blue hue because it easily banks towards cyan which is too bright for headers compared to the normal text, or dark blue which is too hard to read on a black background. Based on feedback, the colour theme succeeded; it’s easy to read, not too jumpy, and page elements stand out quite well. I’m glad to hear that 🙂

To enhance impression, I also did some artwork on the header and footer, to remind of a Game Creation tool here: This business is tied around entertainment after all. It’s not too obvious, but I bet it creates some subconscious images that support CoolBasic as a product. High-resolution textures and reflections create impression of the multimedia involved. And then there’s of course the never-dying logo of the “cool” Ice Cube.

There’s also some tech involved. I don’t have fancy ASP.NET support on my web server, so my options are quite limited of what comes to content publishing systems such as MS Sharepoint or Elevation. So I use PHP and MySQL. In this particular case, I had to integrate with phpBB3 and WordPress databases in order to compose a list of the latest entries shown on the main page. This is the first time I actually need SQL for my webpages, so I decided to do this properly and wrote a complete PHP5 SQL class (objects and classes are not supported until version 5) I can use for later cases, too. Those listings change according to the selected language of the website, too. I’m actually surprised that I managed to get this all running in just one day.

Now that I have stabbed both the official forum PHP code and the blog JavaScript code, I decided to establish a development environment on my laptop. Thanks to this “sandbox”,I no longer have to upload the scripts just to debug/test them. As a result I now have a complete copy of the forum, blog and the website, running on my localhost. All further development can be done locally on my laptop which is fast and painless. This gives me time to test things through properly before uploading to the production environment where the changes “go live”.

Bonus
When I was digging for those old websites, I came across something that you guys have never seen before, but something that apparently was supposed to be the next CoolBasic website. In addition, there’s also a pic of CoolBasic’s supposed new manual front page. These files date back to 2007. Please note that these never went live, and never will. I have something completely different planned for CoolBasic V3 🙂

The unpublished CoolBasic Website, 2007

The unpublished CoolBasic Website, 2007


The unpublished CoolBasic User Manual front page, 2005/2006

The unpublished CoolBasic User Manual front page, 2005/2006

OK, back to Pass#2 coding…

Happy New Year 2009!

Oh snap, how long has it been? Like 6 or so years since CoolBasic was born! Let’s take a few moments to look back. We had a slow compiler stuggling with tons of syntactical exceptions that lead to all kinds of work-arounds and tanglented compiling process. What the compiler ended up producing with, was an unencrypted intermediate code (aka pseudo-code). There was even an option in the editor, to not include the program code into the executable, but to produce a small separate file that could then be “loaded” to the virtual machine. The VM tried to match files in the same folder with similar name to the VM executable itself. Now I laugh at this concept… it was sooo insecure it’s not even funny. Both the compiler and the editor was written in Visual Basic 6.0 and the Runtime was a BlitzBasic interpreter.

Back then, the interpreter was just a renamed executable file which during the compiling process got copied into the new location with its file extension changed into “.exe”, and having the pseudo-code included at the end of it. The interpreter automatically tried to open itself and to read the intermediate code based on a recorded offset where it could calculate its exact position within the executable. Of course, little things such as, say, modifying the icon resource of the executable was not supported because it was possible that the intermediate code offset within the file might not remain in sync wih the recoded offset. In short, the first CoolBasic was quite a mess.

This is only known by those who have been with us since the beginning, but CoolBasic was accused of copying BlitzBasic’s functionality – effectively creating a “wrapper”. This eventually lead to CoolBasic redesign where the Object System was born! I also wanted to get rid of VB6 (it’s simply crap), so I wrote a new editor. Had I been smart I would have written the compiler from the scratch at this point, too. But I didn’t. It’s still a VB6-piece-of-sh–.

The basic way of creating games with CoolBasic was now centered around the Object System, but of course some command sets were still similar to Blitz’s like the sound engine. Unfortunately, getting rid of those it would require a complete rewrite of the Runtime and having CoolBasic not created in BlitzBasic because of its limitations. Blitz was becoming a large problem for me, and I really wanted to dump it and have independant CoolBasic framework!

That CoolBasic is the one you’re using at the moment. Yeah, I know how limited and bad it is. That’s why I started writing it all over about 2 years ago. There was supposed to be a new compiler, new editor, new tools, new runtime. No VB6, no BlitzBasic. Independent platform, and limitless opportunities to plug-in new things. Needless to say, I was a student at that time so the project kind of froze until since I started to write this blog. I reopened the CoolBasic project, but this time I really wanted to get things done right straight from the start (so I don’t need to rewrite CB again next year). The result is CoolBasic V3 being under development. It’s progressing slowly, but as I said, I want to get things done properly. Careful design takes time.

I want CoolBasic to become more like VisualBasic.NET (what comes to the syntax, atleast). It will be fully Object Oriented, and the ways of Procedural Programming will be gone. I can’t emphasize enough how big a step this will be. If I wish to implement new programming trends and get CoolBasic fully competitive with other languages, OOP is the way. If CoolBasic V3 was just a rewrite of the original CB i.e procedural language then it would probably be already done. However, getting the system set up in a way that will support things like classes, polymorphism, inheritance, overloading, properties, unlimited nesting, protected code or even class templates will take very careful planning, and lots of iteration.

So I’ll be around for year 2009, developing CoolBasic V3! I hope it gets published at some time this year 😉

Images and the blind

This is old news (about a month), but due to the extraordinary nature of this issue, I decided to share it anyway. I received an interesting email from someone who’s completely blind. He told me that he couldn’t read the ASCII-table of the manual because it’s there as an image. Now that you think about it, there’s really no reason why the same table couldn’t be illustrated in text as well, and therefore be available to those few who are actually using special equipment to read information on “screen”. In today’s Windows world ASCII-tables are quite irrelevant apart from console applications, so the last 128 characters of the table weren’t even presented in their original DOS-symbols.

Funnily enough, most of the ASCII-tables you’ll find when you browse, for example, results of a Google search, are indeed images. Is it because it’s easier to generate the codes of each individual characters in a form of a table on some “canvas” and then simply screencapture it? Or is it just so much more work to write the HTML-table generation within the loop that iterates the character codes? Maybe we’re just lazy. Either way, I’ll make sure that the next ANSI-table within CoolBasic V3 manual is in pure text format.

The Dragon Book

I finally got my hands on the Bible of all compilers, The Dragon Book. Yep, it’s over 1,000 pages of pure knowledge and covers basically all one would ever want to know about how to make a high-end compiler for modern programming languages. The real name of this epic tome is “Compilers – principles, techniques, and tools”, but the reason why it’s called “The Dragon Book” derives from its cover illustration: There’s a dragon and a knight fighting each other. Inside, however, wall of 8pt text crits you for over 9,000! The books was originally written back in the 80’s, but the fresh second edition was published in 2006. This newer, updated version is the one I currently have.

Greedily I started munching the text, and to my surprise, I noticed that the described techniques are exactly how I’ve been writing the V3 compiler. Good. I probably won’t build the V3 compiler all by the guidelines of this book because there’s way too much information for me to handle at this point. But hey, I can always improve the compiler as I learn more and advance through this book. Mark Sibly (head programmer of Blitz 3D) once said, “When I was making my first compiler I couldn’t understand half the material (books) I had.” I can’t remember what the exact quote was, but you get the idea. I have a feeling that this book will serve me well in the future 😉

Assembly Summer 2008

The annual summer party for coders, gamers, composers and artists took place again in Hartwall Arena, Helsinki Finland. 5,000 people was there! Although this time I decided not to purchase a computer ticket (a seat and a network spot reserved just for you) it was nice to be there again, after 3 years of break. The biggest reason to actually go visit the arena and not just sit home and watch all that from the Assembly-TV network stream, was that there were quite a few CoolBasic users with their desktops and laptops. I felt it’d be cool to go there and say hello face to face. So I did. Thanks to an “organized” topic on the CoolBasic forums, some real meets actually took place where members of community could talk and share thoughts in more “quiet” place. I myself missed all the meetings, but I heard afterwards that they were a success. I did, however, drop to say hello at the seats that were announced on the Assembly topic.

I probably said things I shouldn’t have, but the feeling and atmosphere was so amazing I guess I just accidentally slipped out some surprises about CoolBasic V3 I’d prefer not to ruin at this point just yet. However, now that I think of it, I hope I gave some hope to those who listened to me, that a new version is indeed in development and it’s going to bring a lot more to the table than the current CoolBasic version 2 (which is still at Beta, lol).

As I walked around the arena in darkness it wasn’t hard to spot these guys 🙂 I saw CoolBasic forums and editors open on their screens. I was flattered. It’s rewarding to see people actually using something that you’ve created. They even arranged a little competition of which I saw 4 CoolBasic entries (or they did it just because they knew I was coming to a visit, hehe). In addition, I saw a splendid graphical “demo” made in CoolBasic, covering some nice effects I’ve no idea how they’re carried out code-wise. This whole thing drove some new energy into me, and I feel encouraged to continue. I hear people thanking me for making tem what they are – without CoolBasic some people would never had started coding, and some of them are already growing out of the current CoolBasic due to its limitations. Those limitations I wish to lift in V3.

Again, Thank You!

AeroGlass Candy

I can’t help but keep liking Windows Vista AeroGlass UI. It’s simply amazing. Not an overkill, but impressive enough to get me thinking of it all the time I use Windows. That being said, I recently came across with this article in the MSDN magazine, where this effect was introduced in-depth. I found out that enabling this effect in Windows Forms was not so difficult a task after all. With a simple API, a programmer can enable the blur behind the window, extend the glassy client area, or change the color theme for a single window. All this got me pretty excited, so I thought why not give it a try and play with this little eye candy a bit.

Since it’s practically only about calling the Desktop Window Manager DLL (that ships with Windows Vista), achiving the effect would be easy and independant from the programming language used. I wrote a simple test application in VB.NET, and was pretty satisfied with the results. However, as the current plan stands, only the code editor in CoolBasic project would be written in .NET. All important tools, the engine and the libraries would be written in other languages such as VC++ 6.0 and PureBasic in order to establish as low software requirements for CoolBasic games and using CoolBasic development environment in general. So I tried to achieve the AeroGlass effect in PureBasic too (since it’s used to create some tools), and succeeded at it!

At that moment, I was on fire. Then I tried to apply this effect to one of my tools (Work In Progress, huss). That particular tool had some controls on its main Form. The glassy look worked fine on it, but as soon as you have labels, buttons or other controls, things get messy. The controls had opaque background color whereas their front color was transparent. Meaning that label texts, for instance, weren’t black but appeared in a carved manner. All control texts were difficult to read. Now the control background color isn’t really too much a problem as it’s easy to apply a transparent brush on them. However, fixing the foreground color proofed to be a lot trickier task.

It’s obviously a GDI-related problem: It ignores alpha data whereas DWM takes advantage of ARGB-encoded brushes. It’s possible to set the Form color manually with alpha value being zero, but that way the window transparency would be gone and that’d be completely against the purpose of the entire implementation of AeroGlass. The only solution to this would be to manually draw label texts with standard bitmap blitter – which supports alpha data. All this involve creating bitmaps using DC, in addition to some tricky code for event custom handling. You’d get a text effect similar to Windows Media Player (the Vista version), including the glow behind the text. But buttons and other controls would still render incorrectly. I’ve yet to figure out a fix for this.

AeroGlass could perhaps be applied to the new Editor, but not on the tools such as Auto Updater. I decided not to implement the effect for now.

So today I made a blog!

Hello, everyone!

It really seems that blogs are getting more popular every day. Eveyone has one. I haven’t felt any urge to speak my mind in public before, but this time I might actually have something to say. New version of CoolBasic is in development, so I thought this would be a perfect time to set up one myself. Blogging is a new thing to me, and I consider it exciting – atleast for now 😉

Some people want their voices heard, some people just write things down so they can later return and look back. Be it out of amusement, curiosity, or just for memories. I, personally, am writing this blog just for fun. There’s no catch, no target group, nothing. Just an archive of thoughts on the long road of CoolBasic’s development progress.

Some things are better to be kept in secret. I won’t be going to reveal technical details of how the future-coming CoolBasic is going to work internally (atleast I’m trying not to). There be spies, you know. Instead, those who are interested, might find hints of what to expect. At this point I’m just going to say… if things go as planned, it’s worth waiting!

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress