New BLIde IDE in the works

Most of BlitzMax users know pretty well latest anouce by Mark, regarding a new language in the Blitz familly called (unless this changes) BMX2.

I’ve joined the dev team of this project today, with the idea to make BLIde support this new language. At first sight, while BMX2 should feel very natural for a regular Blitz user, it has some aspects that will requiere a deep rewrite of the internal BLIde engine. This rewrite will be done in order for BLIde to provide things like advanced intelliprompt, and in order for BLIde to support all the new language facets. I can’t (and I won’t) give any details of what’s in the kitchen regarding BMX2, as all information will come from the official source (wich is Mark), whenever Mark feels it’s the right moment, but regarding BLIde, all I can say is that it will not support BMX2 in its current status.

So, as all the internal BLIde parser, lexer, AST engine, debugger and ¬†compiler-driver will have to be rewritten from scratch, I’ve decided to make it in the form of a brand new IDE. This ide will be BLIde for Bmx2 (instead of the current BLIde for BlitzMax). It will be released for free, in alpha form, whenver we have a public beta version of bmx2. There’s no plan or timetable for this new project. The project is currently on a planing status, and I’m not sure when it’ll see the light of day. Anyway, I’m very excited with it and I hope most Windows Blitz developers will find it useful.

Improved intelliprompt

We  are developing a new Intelliprompt system in BLIde that produces improved suggestions as the user writes code.
This new intelliprompt system is based on the mixture of several ideas. In one hand, BLIde now integrates an internal dictionary with all BlitzMax reserved words, including type declaration words, loops, etc. So they’re avaiable for completion as the user types code. In the other hand, BLIde now can get a list of available local variables in the given cursor position and, additionally, it can be mixed with the current type self-defined keywords such as fields, methods, functions etc. All this, is mixed at realtime with all solution-scope defined classes, functions, globals, methods, fields, const, etc. and, at the very end, BLIde is able to add any module-database-defined keyword so… all in all… BLIde now is able to provide an incredibly exact completion paradigm.

This new paradigm allows BLIde to case correct local variables and scope-based declarations as never before so. This is now being beta-tested and we’re hoping to have an stable version in some weeks time.

Windows 7 64 bits and GDI+

Another glorified weekend trying to fix a bug on BLIde that turned out to be a bug on the .net implementation of GDI+ when it is used on Windows 7 64 bits.

It’s a joy to see how the Graphics (GDI+) object that the underlying engine is giving you at a draw operation in a combo box, can have a transformation matrix applied to it, randomly, sometimes, and only on windows 7 64 bits, obviously when using windows forms.

This is maybe the most inconsistent bug I’ve ever seen on .net and I supose they’ll fix it but, just in case, if you’re developing a .net application that uses internally custom GDI drawing operations, be sure to reset any transformation matrix before any draw operation!!

Oh glorious VMWare!

When you have been working with windows forms applications and deployed them for public consumption, you know you can face a ‘nasty’ handycap. How will your application look and perform when runned on other peoples configurations?

While this problem is minimized drastically when using the .net framework, there’s still one area that can drive you crazy. I’m talking about modified DPI windows installations. If your application users do have a modified scaling in their windows you can be sure your application won’t display properly at some point.

The good news is that there’s an easy way to get rid of this if you’re using VMWare. Just install a virtualized Windows in your host computer and modify all the settings so you can see (without having to reboot) how your application behaves on different DPI configurations!

Good bye windows registry

Early versions of BLIde did have a big dependence on the windows host machine registry to store some data (like recent documents list, active skin, etc). While BLIde development has evolved, I’ve made several efforts to make BLIde as much registry independent as possible and, the good news is that next BLIde Plus update (00.09.93) will be completely registry independant. One step forward on making BLIde portable.

The data that is currently stored in the windows registry will be cleared from there as requested on the next BLIde update. That is, whenever a setting stored in the windows registry is requested, next BLIde versions will get it from register, return the value, store it in the BLIde settings area, and remove the setting from the windows registry, leaving the registry completely clean.

The idea behind this is to add a new feature to BLIde that will allow BLIde users generate a working copy of BLIde + BlitzMax (everything setup and connected) on a pen drive or portable storage device.

With this ‘portable’ copy of BLIde + BlitzMax, the user will be able to compile, execute and debug code from any computer with windows vista, windows 7, or earlier windows with .net . That can be very helpful when the time to debug an application on several architectures comes. Additionally, all your BLIde setup can travel with you, whenever and wherever you’re going to have a coding session.

Obviously the portable version will come a bit later… :D