NewsForumsCodeLogsGallerySpecsSearch

BLIde 0.7.51 released

BlitzMax Forums/BlitzMax Programming/BLIde 0.7.51 released

ziggy(Posted 2006) [#1]
Here's a new update of BLIde, this time there are just some new features,:

-Bug Reporter
-Jump to definition (not much usable yet, as it only recognizes types and some globals, but it's being improved)
-Unicode support (by default saves to unicode, but it's customizable)

FIXED: a lot of bugs and stability issues have been solved. Last time I counted the bugs/lags solved for this version, the number was about 170... :D

Note that this version doesn't requiere .net 1.1 any more. If you don't have .net 2.0, the set up will download it for you.

hope you find it useful,
happy coding


Booticus(Posted 2006) [#2]
You rule!


Tiger(Posted 2006) [#3]
Like it, alot!
Thanks ziggy.


Bremer(Posted 2006) [#4]
Thank you for your continued work on this. Its appreciated.


Picklesworth(Posted 2006) [#5]
Yay!

Still opens a brand new instance of BLIde if it's already running when I open a BMX file through Explorer. (With most editors, this file would open in a new tab the already open instance, or at least be running with the same process in a new window).
Is it possible to fix this to some extent?

Still, Nice job. Definietly runs better :)


ziggy(Posted 2006) [#6]
@Mr. Picklesworth, this is something I'm working on for a next release.


NoBoDo(Posted 2006) [#7]
Ziggy,
Thanks for the update. Fantastic work you're doing on this!

Mark.


ziggy(Posted 2006) [#8]
tinny update to 0.7.52 is available to fix a little stupid issue with intelisense in very large projects. Not important update, but recomended. New build also opens bmx files from windows to the existing instance of BLIde instead of opening a new instance. (thanks to Mr. Picklesworth for his suggestion)


Sin of Nature(Posted 2006) [#9]
Brillant update! You've fixed the only thing that drove me mad about Blide. Adding a function between other functions used to unfold all functions below it! That was so frustrating.

Good work!

Sin


Beaker(Posted 2006) [#10]
Does BLIde support split window views? (ie. so that you can view 2 different parts of the same document?)


Booticus(Posted 2006) [#11]
Yes! Grab the little horizontal line above the scrollbar arrow on the right side of the source code window and drag it down. Sorry, can't post a screenshot yet!


ziggy(Posted 2006) [#12]
yes, it can make splitviews, here you've got a snapshot:



Sean Doherty(Posted 2006) [#13]
ziggy,

Is there a way to set the editor so the code is not folded by default and still allow for folding? I can only see how to turn folding on and off.

Thanks


GfK(Posted 2006) [#14]
File> Settings> Preferences

Editor tab

Fold All at Load Time


Sean Doherty(Posted 2006) [#15]
Thanks, totally missed that option.


NoBoDo(Posted 2006) [#16]
Using BLIde 7.52...
using BlitzMaxPath() causes:

Unhandled Exception:Unable to locate BlitzMax path
I verified that BlitzMaxPath() works in the standard IDE.

I tried to use the new 'Send bug report' functionality but it just brings up a blank screen with caption 'Report a bug', the BlIde graphic below that, but nothing else visible on the screen but a non-working scrollbar?


ziggy(Posted 2006) [#17]
@NoBoDo: This is a BlitzMax function, it only works if the final executable is located inside the BlitzMax path. copy your application to the My Documents folder, run it from there, and you'll see it doesn't work.
The same applies if you create your application from BLIde, and you save it in the BlitzMax Path or somewhere inside the BlitzMax Path. you'll see it working. So... this is not really a good function to locate the BlitzMax path, unless your EXE is placed already in the BlitzMax path... not much usable... this function was working in the standard IDE becouse the temp bmx file or your bmx file was already saved in the BlitzMax path. Take a look to the function in the mods folder, and you'll see exactly what I'm talking about:
Function BlitzMaxPath$()
	Global bmxpath$
	If bmxpath Return bmxpath
	Local p$=getenv_("BMXPATH")
	If p
		bmxpath=p
		Return p
	EndIf
	p=AppDir
	Repeat
		Local t$=p+"/bin/bcc"
		?Win32
		t:+".exe"
		?
		If FileType(t)=FILETYPE_FILE
			putenv_ "BMXPATH="+p
			bmxpath=p
			Return p
		EndIf
		p=RealPath( p+"/.." )
		If p="<bad_dir>" Throw "Unable to locate BlitzMax path"
	Forever
End Function


Note that this function will work as spected if the user of your application creates an evironment variable pointing to the BlitzMax path. (it's the only good way to use this function), but in that case, I would recomend you to use the command getenv_("BMXPATH") directly. so, no BLIde bug here. Take in consideration that any environment variable created from an EXE, is deleted after EXE execution, unless it's created 'by hand' by the windows user. (that's why this function doesn't work properly in most cases)

To the other bug you mentioned, The BugReport Utility uses an on-line flash form to send the report. It may work, as I've received some reports. There could be a puntual connection problem (you know internet...) or you have a very old version of the Flash PlugIn.


By the way, many thanks to everybody for their possitive feedback. :D


NoBoDo(Posted 2006) [#18]
@Ziggy,
Looking at the function itself, I can see why it would fail, it makes me wonder what the purpose of it is.
Thanks for the detailed response.

On the flash - I have a current version of the flash plugin. I just looked again this morning and the BugReport is still a blank window, so if it is an internet connection problem it is outside my network and somewhat persistent.

Thanks,
Mark.


ziggy(Posted 2006) [#19]
@NoBodo: I will change the way the Bug Report is shown in order to ensure any ActiveX compatibility issue for next BLIde version


NoBoDo(Posted 2006) [#20]
@Ziggy,
I see what the problem is with the 'Bug Report' screen.
I am guessing you have an Internet Explorer browser on the 'Bug Report' screen, and that is what is hosting the flash form.

The problem is that I never use Internet Explorer, so of course never updated the flash plugin that is installed in IE. I always use Firefox, and keep the flash updated there.

I just updated the flash plugin in IE, then reloaded BLIde. Now the Bug Report screen works fine.

I'm willing to bet there are a lot of people who use Windows but don't use Internet Explorer, so don't have the latest flash plugin installed to IE.


ziggy(Posted 2006) [#21]
@NoBoDo: I have been making changes to this issue, next version will open the Bug Report form in the user's default browser, to avoid this kind of problems, so it will work ok on firefox, opera, IE, etc.


Sean Doherty(Posted 2006) [#22]
@Ziggy,

Here are some bugs:

1) Bug Reporter does not work. It just opens a dialog box with no where to type. I think you have this one.

2) Change the code to something that won't compile. Compile. Press CNTL Z for undo. Compile it is still sees the old code.

3) The console does not seem to be displaying everything. I find I have to press clear for it to work; it seems to be holding the remaining output in certain conditions.

4) One of my files doesn't open in wordpad "looks screwed"; but it opens in Blide? Not sure this is an issue.

5) The types are poping up in commented code when I type a period.

6) Also, when I type something that is new in the list of popup types (because it has been inherited) and press space it chooses from the list.

Thanks


ziggy(Posted 2006) [#23]
@Sean doherty: I'm working in a new version, and hope all this will be fixed soon. I'm also making a simple-layout mode and some little improvements to parser speed.
the file you can't open in your wordpad may have been saved in unicode big endian, it should open in the standard ide, blide and in wordpad (unless you have a old windows version, or you disabled unicode support, wich is not a good idea for multilanguage and multiplatform compatibility). Ah and another thing, the autolist should show all inherited methods, types, etc. if it's not showing them, let me know and please, provide an example to be sure everything is being parsed as spected.

Thanks a lot for helpingme improving BLIde. :D


NoBoDo(Posted 2006) [#24]
Using Blide 7.5.2, I seem to have found what I would consider a major bug.

At first I noticed that any .bmx file saved from Blide would display as garbage in MaxIDE (using CE 1.15 there). I tested that several times, and got the same results each time. The results are the same regardless of whether the .bmx was created in Blide or if it was created in MaxIDE. As soon as the file was opened/saved from Blide, it would only display two upper ascii characters in MaxIDE.

Then I noticed that a pre-existing file (not created in Blide) doubled in size when saved from Blide.

Ok... so I made a copy of a .bmx that had not been opened in Blide, and opened/saved one of the copies in Blide. As before, the file doubled in size. I opened both in a text editor (UltraEdit) and they both looked the same. Hmmm. Then I switched to binary view and it all became clear. Hex character 00 is being saved after every other character!

Example:
The word SeedRnd, not saved from Blide:
53 65 65 64 52 6E 64
The word SeedRnd, saved from Blide:
53 00 65 00 65 00 64 00 52 00 6E 00 64 00

Apparently this doesn't matter to the Bmax compiler, but of course it does matter to other apps!


ziggy(Posted 2006) [#25]
@NoBoDo: It's not a bug in BLIde, but a bug in MaxIDE CD edition. Let me explain what's hapening:

BMX files are saved in unicode big endian. This sub-format allows more than 256 different characters. (double size becouse each character is represented in 16 bits) it's not a bug, it's an standard sub-format very used. this subformat allows the integration of japanesse and chinesse characters, cyrillic chars, greek, and a lot of the regional-speciffic characters such as Ñ Ý Ç ä and so on... without having to worrie about charset code pages. It also alows your code to be opened by people with a chinesse, japanesse or any other windows regional settings.

You can disable this subformat in the BLIde preferences dialog if you want to get sticked to the windows ansi code tables. Take in consideration that the blitzMax compiler works well with unicode files, and it's a good way to forget about compatibility charset issues, ensuring the portability of your source code.

The Max IDE CE edition don't handle well unicode files, BLIde, UltraEdit, NotePad, official MaxIDE and most MacOs and Linux editors handles them well. (WordPad has some compatibility problems in some windows distros becouse it's using a old version of the MsRichTextBox.ocx).

So.... no BLIde bug here. (maybe the MaxIDE CE should arrange this unicode support bug?)


NoBoDo(Posted 2006) [#26]
I see...
I turned that off as soon as I read your post.

That must be turned on by default; it is not a setting I would have ever turned on! It doesn't make sense to me to double the size of source code files and cause other programs to not be able to read the code just because of the EXTREMELY low chance that somebody reading my source code is going to have character set issues.

Thanks for the response, ziggy!

Mark.


ziggy(Posted 2006) [#27]
@NoboDo: Obvioulsy you're not japanesse, hehehe, I'll add a new page in the first-run configuration wizard to let the user choose if he or she wants that unicode compatibility enabled or not. I think this will be the best way to solve this.

I'm happy to see you have understood it was not an easy decision for me, as BLIde has some chinesse users. I hope this new page in the first-run wizard, with a good explanation, will solve this confusing issue.


Hotcakes(Posted 2006) [#28]
It's not a 'bug' in MaxIDE CE as such, more a missing feature. Does the official MaxIDE (120f or g or whatever) have unicode/16bit support?


ziggy(Posted 2006) [#29]
@Toby Zuydveld: Yes, it has unicode support. anyway, I've posted this bug to the MaxIDE comunity edition thread, to help the MaxIDE CE contributors to solve it.


NoBoDo(Posted 2006) [#30]
I don't know that it is a problem needing to be solved in the CE; is there really much demand for it? I'll bet in priority this would be way below other CE enhancements because it would be a useless addition for most users.

My recommendation for Blide would be to leave things as they are, but make this option default to off instead of default to on. I don't know that adding it to a configuration wizard is worth the time involved. I'm willing to bet that most users would turn this option off once they realized it doubled the size of their source code, and made their source code unreadable in some editors.


Byteemoz(Posted 2006) [#31]
I think the fact that the BMX compiler can read unicode-files is enough 'demand' to add it to the CE IDE (which can now read and save unicode-files).

-- Byteemoz


NoBoDo(Posted 2006) [#32]
I think the fact that the BMX compiler can read unicode-files is enough 'demand' to add it to the CE IDE (which can now read and save unicode-files).
It's nice for those wanting it that it now has that ability - but I would hope that it doesn't save as unicode by default?

On my systems and OS language settings at least, the IDE that comes with Blitzmax (1.20) will read unicode files created by Blide, but saves all files as non-unicode (even those previously saved as unicode by Blide). I just opened in the MaxIDE 1.20 three unicode .bmx files originally created in Blide, that can't be read by CE 1.15. They were sized 25kb, 12kb, and 16kb. Saving from MaxIDE 1.20 and they are 13kb, 6kb, and 8kb and can now be read by CE .


Byteemoz(Posted 2006) [#33]
No, the default encoding is still Latin-1 (unencoded/plain text) .
Unicode (UTF-16) encoding will only be used if the code contains unicode (e.g. Japanese) characters.
-- Byteemoz


NoBoDo(Posted 2006) [#34]
@Byteemoz -- thanks, that sounds great, and I'm glad to hear the CE won't be saving as unicode by default.

Mark.


ziggy(Posted 2006) [#35]
Next BLIde version will have 3 saving options:

1.- Save always as Unicode (16 bits per char)

2.- Save always as ANSI (8 bits per char)

3.- Save as Unicode when needed (8 or 16 bits per char, depending if the source code has spetial chars or not) This option is the same as in the official IDE, it's a little bit slower becouse it has to check the existance of spetial chars before saving, but it's a good option. This will be the default encoding option in next version.


computercoder(Posted 2006) [#36]
ziggy: how bout a Linux version? I like your IDE. Its so familiar with .NET, and its very eyecandy-ish!

Truthfully, I'm working on one as we speak! I just haven't released anything about that just yet, as its still very much in its infancy.

I do use BLIde in windose when I program there though. Mostly I'm in Linux. Like now. ;)

Keep up the great work!


ziggy(Posted 2006) [#37]
@computercoder: Thanks for the possitive feedback! By now, a Linux or Mac version is completly impossible. All BLIde source code runs under the .net 2.0 framework, and migrating this to mono, in current mono state... is just impossible. Maybe in the future.


Sin of Nature(Posted 2006) [#38]
I really like this editor, but that unicode on as default is extremely annoying.

Sin


ziggy(Posted 2006) [#39]
Finaly, the unicode functionality will work this way:
BLIde will detect the best encoding when saving a file (I've found a ultra quick way to do this). So, for regular files, everything will be saved in ANSI subformat, but if the file you're editing has any spetial or regional character, the file will be automaticaly saved as unicode. This is the way the official IDE does, and I think it's a good way to ensure cross-portability of source code.