Cannot build MaxIDE

I`m trying to build the MaxIDE from the latest SVN version of BMax and although it seems to build fine when I run it it gets stuck on the loading BMax splash screen.

Any ideas as to what may be causing this? Also, is this the same as build 4 of the IDE that can be downloaded in another thread?

Jason.

Anyone else getting this?

Jason.

Try renaming the ini file in the blitzmax/cfg folder. I have experienced in the past project paths that can cause such problems.

Strange, I'm getting this behavior too.

It appears to be locking up somewhere in LoadDir() when I import MaxGUI.Drivers and build in release mode.

Running in debug mode, or swapping MaxGUI.Drivers for MaxGUI.Win32MaxGUIEx seems to fix it though...

I'm suspicious to think this maybe something to do with Brucey's Unicode fixes. :(

Does it pick the "other" Win32MaxGUI by default?

No. Although it loads both drivers, only the latest MaxGUI.Win32MaxGUIEx is used on Windows XP+.

Edit: Twenty or so Print statements later, I've narrowed it down to the CloseDir call in LoadDir() when accessing the following path:

C:/Program Files/BlitzMax/docs/html/Modules/Miscellaneous

This appears to work, though...

Import MaxGUI.Drivers

Local tmpFiles$[] = LoadDir("C:/Program Files/BlitzMax/docs/html/Modules/Miscellaneous")

Print "Done!"

OpenDir calls _wopendir
NextDir calls _wreaddir

... they seem harmless enough...

Yeah, I can't get it to crash outside of MaxIDE.

Import MaxGUI.Drivers

Const PATH$ = "C:/Program Files/BlitzMax/docs/html/Modules/Miscellaneous"

Repeat
	WriteStdout "Loop"
	Local tmpFiles$[] = LoadDir(PATH)
	For Local tmpFile$ = EachIn tmpFiles
		If FileType(PATH+"/"+tmpFile) = FILETYPE_FILE Then
			Local tmpString$ = LoadText(PATH+"/"+tmpFile)
		EndIf
	Next
	WriteStdout "ed~n"
	Delay 50
Forever

And neither you should :-)

There must be something else going on...

It's definitely something with CloseDir() - commenting that line out of LoadDir$() "fixes" it LOL :P.

I don't know if this is of any relevance, but the handle of d is exactly the same as all others previous file handles ReadDir() returns so all the other calls seem to have cleared themselves up.

CloseDir? Ah... maybe. I didn't touch that one.

How come today I can't find "_wreaddir" (or any of the others) on MSDN? They were there last week...

Okay.. this patch, stdc_mod_updates.zip should fix the issues with LoadDir. (the two files replace those of the same name in pub.mod/stdc.mod)
Hopefully Mark will find time to update SVN at some point with all the patches I've sent him recently.

Yup that seems to work good Brucey.


I had a quick go at getting MaxIDE to support unicode in the output window, my rather lame first attempt seems to be working ok, but proper utf8 needs a little more logic.

It just needs a replacement TOutputPanel.Write method:

	Method Write(utf8$)
		Local mess$,i,c,d		
' convert utf8 bytes to unicode
		For i=0 Until utf8.Length		
			c=utf8[i]
			If c<128 
				mess:+Chr(c)
				d=0
				Continue
			EndIf
			If d
				mess:+Chr((d-192)*64+(c-128))				
				d=0
				Continue
			EndIf
			d=c
		Next
' and write to output panel
		mess=mess.Replace$(Chr(0),"")
		If Not output Open()
		AddTextAreaText output,mess
	End Method

A better fix would be some sort of String.FromBytes helper function that supports an encoding parameter perhaps...

Thanks for looking into this guys, much appreciated.

Jason.

Skid, take a look at the bottom of brl.mod/blitz.mod/blitz.bmx :-)

bbStringFromUTF8String
bbStringToUTF8String

I previously sent Mark an improved version of those functions too, which takes care of the "4th" byte (so we can hande all 1.1 million characters... ack!).

Yeah, I sent Mark an e-mail a week or so ago asking for a $u8 external declaration type and some String.FromUTF8() and String.ToUTF8 functions... This would also help enormously with making FLTKMaxGUI support UTF8.

Except that requires core changes to bcc, I would think. (for it to generate the correct calls when interpreting strings?) - just guessing.

Hence the two (albeit .bmx based) helper functions.

I'd have implemented them lower down, but my C sucks... :-p

Yeah - I better get on Mark's good-side then...

Latest SVN update fixes the issues with stdc, as well as the win32maxgui bug related to building threaded.

Still awaiting one more update for 4-byte/2-word UTF conversion support, then it should be all set :-)

Righty... the UTF-8 conversion functions should now be able to convert between all 1.1 million characters.

If you are American, I believe it still supports the first 127 :-)