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.

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.

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!!

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!

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

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.

In order to make SDK development easy and powerful, 2 things where implemented in BLIde:

a)      A BLIde VSIntegration framework that does most of the low level reflection based work (so it is very easy to write a BLIde plug-in using Visual Studio).

b)      A pre built Visual Basic solution with an empty plug-in that can be used as a template.

The VSIntegration framework is part of the internal BLIde core, so in order to get it; all you need is a properly installed version of BLIde Plus. It is highly recommended to install this copy of BLIde Plus to the default “c:\Program files\Blide for blitzmax” location.

Then, the pre built Visual Basic solution can be downloaded here: http://www.blide.org/sdk/BLIdeSDKProject.rar

Unrar this file to any destination on your system. (the user documents folder is highly recommended on system with User Account Control systems like Vista or Windows 7).

When you unrar this package, you’ll see a solution file called: BLIdePluginDevelopment.sln Double click this file to open it on Visual Basic 2008. (for more information about this solution template see here).

As you can see, the first thing we see when the solution is open is the Project properties of the Plugin. Be sure that the first reference (BLIde) is not marked as ‘unresolved’. If you’ve installed BLIde on c:\program files\BLIde for blitzmax\ it’ll be automatically resolved. Otherwise, you will have to select the unresolved BLIde reference, remove it, and then add it again from the proper BLIde installation. In this case, be sure to set the copy local property to false.

Then, it is a good idea to select the Appliction tab in the same Plugin window:

In this window, it is a good idea to give the Plug-in assembly a name. This will be the name of the plug-in. It has to end with .sdk If you don’t end it with .sdk, it won’t work!

By default the plug-in will be name untitled.sdk

Also, notice how the root namespace is left blank. This is also mandatory. Otherwise the plug-in will not be compatible with BLIde.

When this is done, we can close the plugin project properties window, and select the file BLIde Launcher.vb

This is the contents of the file:

'Modify this const according to your BLIde installation and plugin name:

Const BLIdeLocation As String = "C:\Program files\Blide for blitzmax\BLIde.exe"

Const PluginName As String = "untitled.sdk"

We should modify the BLIdeLocation const (if BLIde is not “c:\Program files\Blide for blitzmax\BLIde.exe”), and also we should modify the PluginName const, with the name of the plugin we’ve set in the previous step (in the Plug-in Assembly name window).

After changing this constants (if needed), we can close the BLIde Launcher.vb file and see the PlusingModule.vb file. This file contains the Plugin source code that, by default contains the code to display a hello world message box:

Imports BLIde.SDK
Public Module Plugin
Sub Main()
IO.Msg("If you see this message, you've set up the VS project properly!", "Hello world!")
End Sub
End Module

If you press F5, you should see how the SDK launches BLIde with this plugin, and BLIde shows the Hello World message at start-up.

For more information see: http://blideide.wordpress.com/2009/08/26/getting-ready/

The funniest thing of it, is that I did get an answer from MicroSoft when I did sent the bug report. The answer was that there was a bug in my code (they did not see the code) but that it could be solved overriding the WndMsg method of the TreeView class in C#, and adding a Invalidate call when the message was a SW_VSCROLL message… mmm… that makes me wonder how could they have such a quick answer without seeing a single line of my code :)

Anyway, this has been extremely helpful and it seems I will be able to solve this visualization bug soon. (I hope so).

Next BLIde version will also inherit automatically the bbdoc information of the overloaded method or function, so methods and functions are kept always on its common/all tab when using intelliprompt, and also, the maintenance of the code is easier, as it is (sometimes) automatically documented.

As an example, when I’m writing this:

Type MyClass Extends TList
    Method AddFi
End Type

BLIde brings the intelliprompt window, and if I select Addfirst, BLIde will automatically add this code:

Type MyClass Extends TList
   Rem
      bbdoc:Add an object to the start of the list
   End Rem
   Method AddFirst:TLink( value:Object )

   End Method
End Type

The inheritance of documentation is done from the direct parent class until a overloading super class providing an implementation of the given class is found. Then, documentation is inherited if available. Otherwise, the method or function is considered undocumented and no bbdoc statement is added.
That means that documentation chain can be broken and re-implemented at any point of the genealogical class tree, and BLIde will understand it and handle it accordingly.

The good news is that this new Plug-In has been written completely on Visual Studio Express 2008, using Visual Basic .net as the programming language so, no need to write BLIde Plug-ins from within BLIde any more. (this will still be supported for small plug-ins). That opens the door to the creation of much more rich, big and complex BLIde Plug-ins to third party developers. -I promise to document this soon.

This new Plug-in will be ultra easy to use. Just select a field name (or place the cursor over it), open contextual menu and select the option ‘generate getter and setter’. BLIde then will do all the work for you, including a small bbdoc: schema for the new two methods.

Hope to have this available for all BLIde Plus users very very soon.