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

BLIde SDK – Getting ready

BLIde SDK.

Getting ready

This is a first brief explanation on how to develop a BLIde Plug-in using the BLIde SDK.

Those are the prerequisites for this process:

1. BLIde Plus 00.09.91-A or greater.

1. Visual Basic Express Edition 2008 or greater (a tutorial based on C# is planed and will be published later).

First of all, while I was trying to create an easy step-by-step guide on how to integrate Visual Studio with the BLIde SDK framework, I noticed there was not an easy and simple step by step way of integrating things. The simplest integration required about 100 lines of code and a considerable knowledge about .net reflection and assemblies.