64-bit Windows MaxGUI

BlitzMax Forums/BlitzMax NG/64-bit Windows MaxGUI

Brucey(Posted 2015) [#1]
Happy Holidays! :-)

I've just committed the first version of the Win32MaxGUI upgrade to support 64-bit apps. (source viewable here : https://github.com/bmx-ng/maxgui.mod )
It's been a hard slog over the past week since I started work on it, but most things generally appear to be functional now.
Most things except images, that is, which have so far failed to appear on any of my windows.

On the other hand, MaxIDE builds and runs (as a 64-bit app) and is more-or-less useable, if you accept blank toolbar buttons as useable ;-)

Obviously, the outstanding problems will be fixed at some point, but I thought I'd commit it in its current state so others can have a play and perhaps pick up on anything else that I've missed.

NG's maxgui.mod requires the latest of everything to build correctly (bcc, bmk, pub.mod and brl.mod)


GW(Posted 2015) [#2]
Cool! looking forward to trying it out. Thanks!


Henri(Posted 2015) [#3]
Hi,

nice work, seems finally coming together. Promise I will give it a spin this week :-)
Any big hurdles left ?

-Henri


degac(Posted 2015) [#4]
Wow!
Nice Xmas present!

I'll download it this evening, I *need* MaxGUI :)


Brucey(Posted 2015) [#5]
Fixed the images issue. All the MaxGUI "doc" examples are working, and MaxIDE looks mostly okay.

I still need to sort out manifests, icons and printing.


xlsior(Posted 2015) [#6]
Great!


Brucey(Posted 2015) [#7]
With 64-bit icon/manifest integrated, MaxIDE looks really nice now, and has been stable so far.
Am now using it as my default MaxIDE on Windows - well, it needs testing ;-)


skidracer(Posted 2015) [#8]
That is one heck of a milestone, awesome stuff!


Thareh(Posted 2015) [#9]
Nice! I'm about to start coding on a MaxGUI project, I'm definitely gonna try this out!

Thanks for all your hard work Brucey! :)


degac(Posted 2015) [#10]
I think I'll wait the pre-compiled .zip file to download it :)

I'm quite good in cooking, but even if I followed the 'recipe' (the tutorial), something (I think) is gonna broken :D!


Thareh(Posted 2015) [#11]
A small remark to Brucey: The font chooser in MaxIDE (64-bit) isn't working, atleast not on my computer =P


Grisu(Posted 2015) [#12]
Wow, that's great news! Thanks Brucey!

Is there a tutorial on how to set this up properly? I'm still using the native compiler / gui. Or a Zipfile with all files needed as Christian mentioned?

Can I use your FMod module with the 64bit dll in the future as well?

I would love to port my PRP over, if possible. :)


EdzUp MkII(Posted 2015) [#13]
Very nice might actually come back to BlitzMax for a project I have in mind as its best for rapid development and testing :D


Thareh(Posted 2015) [#14]
@Grisu

- Download BlitzMax NG from here: http://www.bmx-ng.com/main/downloads/
- Download bcc, pub.mod, maxide (if you want to compile 64-bit MaxIDE), maxgui.mod, bmk & brl.mod from https://github.com/bmx-ng (click on each and there's a "Download ZIP" button on the right side of the screen)
- Compile bcc & bmk (threaded build recommended for faster compilation later) using the instructions on github (you can compile using BlitzMax NG) and place bmk.exe, core.bmk, make.bmk & bcc.exe in BlitzMax NG\bin folder
- Copy the downloaded pub.mod, maxgui.mod, brl.mod to the BlitzMax NG\mod folder (I removed the old ones before copying)

Something like this, I successfully compiled MaxIDE 64-bit using this method =P


Grisu(Posted 2015) [#15]
And I would need to install GCC with 64 Bit as well. I fear to miss or mix important files. But I'll try. Thanks!


Brucey(Posted 2015) [#16]
The font chooser in MaxIDE (64-bit) isn't working

Thanks. It was passing the wrong handle into the function. Fixed.


Brucey(Posted 2015) [#17]
And I would need to install GCC with 64 Bit as well

I'll try and get a new release done soon.

Can I use your FMod module with the 64bit dll in the future as well?

Yes. I've just updated bah.fmod with the new 64-bit Win32 dll. The examples play fine as 64-bit apps.

In theory, you would just do a recompile of your app with 64-bit enabled, and it would all *just work*, but that may depend on other factors like anything you've done outside of standard BlitzMax (like using pointers via ints, calling windows APIs directly, etc). And of course you need to be at least "Strict". ;-)

There are still likely to be some issues with the MaxGUI port (as Thareh discovered!) as I can't really exhaustively test everything myself. However, report them as I'll sort it out as usual.


Grisu(Posted 2015) [#18]
By new release do you mean some kind of installer package for bmx64?

I'd like to help testing. But I need to set it up properly.

Got your Fmod update from SVN. Please make sure you also update the files inside the "include" folder to match the latest version. From my experience this is needed.


Derron(Posted 2015) [#19]
Just follow the described steps (download bcc bmk etc... compile and copy...)

As soon as you use NG you are able to put the "to use" MinGW within the folder (blitzmax/MinGW32 or so...) and it will automatically get used instead of an other installation.

If you put everything in an extra folder.. you should not break your existing installations. You could call bmxng portable...similar to bmx vanilla (which uses the fasm binary included in its download instead of MinGW).


Bye
Ron


Brucey(Posted 2015) [#20]
By new release do you mean some kind of installer package for bmx64?

It will be a self-contained rar with MinGW included, as per the previous releases. I've found it's easier to get most Windows users up and running if you give them everything they need in one folder, with zero configuration requirements ;-)

I may even get a release done before next year...


Brucey(Posted 2015) [#21]
New release is available at https://github.com/bmx-ng/bmx-ng/releases


Grisu(Posted 2015) [#22]
Awesome!

Runs "out of the box" and recompiles all modules fine. I doesn't detect the FASM version if that is an issue.

The compiler doesn't like this line:
Local hdrop:Int = GlobalAlloc( GHND | GMEM_SHARE, sz) ' line 104

"Unable to compile from Byte Ptr to Int."

Source:



Brucey(Posted 2015) [#23]
There's a good example of low-level API code that makes assumptions about pointers :-)

GlobalAlloc() returns a pointer, not an Int.
ReleaseMutex() takes a pointer as an argument.
CreateMutexW() returns a pointer.
For GetWindowModuleFileNameW(), hwnd is a pointer.
For GetModuleFileNameW(), hmodule is a pointer.

etc... ;-)

None of that stuff will work with 64-bit because pointers are 8 bytes, not 4 bytes (as they are on x86), and generally it is better to use Byte Ptr in those cases (as I've always tended to do with my modules, and which made the migration to 64-bit mostly painless).


Grisu(Posted 2015) [#24]
Ok, I'll comment it out for now.

Next error:
C:/BlitzMax/mod/axe.mod/oggsaver.mod/oggencoder.c:11:30: fatal error: vorbis/vorbisenc.h: No such file or directory

The file "vorbisenc.h" is present, but the compiler doesn't seem to reach it?


BlitzSupport(Posted 2015) [#25]
Using that latest release, I have no problems with it building modules on-the-fly while building projects, but for almost every project I try to compile, I get an error along these lines at the end:

Building untitled1
[ 97%] Processing:untitled1.bmx
[ 98%] Compiling:untitled1.bmx.gui.release.win32.x86.c
[100%] Linking:untitled1.exe
C:/Users/James/Desktop/BlitzMax/mod/pub.mod/win32.mod/win32.release.win32.x86.a(com.bmx.release.win32.x86.o):com.bmx.release.win32.x86.c:(.text+0x6b3): undefined reference to `_imp__IIDFromString@8'
C:/Users/James/Desktop/BlitzMax/mod/pub.mod/win32.mod/win32.release.win32.x86.a(com.bmx.release.win32.x86.o):com.bmx.release.win32.x86.c:(.text+0x6f0): undefined reference to `_imp__StringFromIID@8'
Build Error: Failed to link C:/Users/James/Desktop/BlitzMax/tmp/untitled1.exe
Process complete


Just tried with this and got the same:

Print "Hello world"


I just downloaded, unzipped and ran from the above link -- I assume it picks up my MinGW64 installation, as I get the option to build for that, too, but the error occurs regardless of x86/x64, debug/release mode.

I've also tried deleting the existing .bmx folders to no avail.

Looked up "IIDFromString" online but... I'm not much wiser! (Other than it seems to be Windows-specific.) Any ideas what might be causing this?

EDIT -- this builds/runs!

Framework BRL.Retro
Print "Hello"


No idea why, though... I got originally similar results for a graphical program that used Framework BRL.GLMax2D (but didn't use GL directly) -- it was one of the few projects that built fine, but with Framework commented out, it failed, so presumably Framework is simply excluding whatever is causing the actual problem.

(Testing on Windows 7 64-bit.)


BlitzSupport(Posted 2015) [#26]
Did some digging, but still not found what's causing it -- did find that BRL.Timer seems to fail to build, though (unrelated to above).

The below simply uses BRL.Blitz for Framework (required for Print, the actual program being Print "Hello world") and then tries to manually import everything else, using MaxIDE's right-hand modules menu for the high-level modules, then (indented) the remaining individual modules...

Assumed this would trigger the error somewhere, but it doesn't... :/



No idea if this will help!


Brucey(Posted 2015) [#27]
com.bmx needs to import "-lole32" for those IID functions.
timer.bmx needs to import BRL.SystemDefault ;-)
(fixed on github)

Thanks for testing!


degac(Posted 2016) [#28]
Hi
Welcome in the 2016 (time-zone permitting & wake up time :D)!
Just downloaded the new package, updated BRL.MOD and PUB.MOD, the 'basic' example (Print "Hallo") now it works without problems (by the way it was the same error I got...)
Tested with an example (firepaint.bmx), and it compiles without problems (after 'stricting' the source code).
tested a MaxGUI example (CreateWindow.bmx) and I got this

UNHANDLED EXCEPTION:ATTEMPT TO ACCESS FIELD OR METHOD OF NULL OBJECTS

And this line in (win32maxguiex.bmx) is highlighted
maxgui_driver = New TWindowsGUIDriver


tested on win7 (x64)

ps:

BMX-NG now uses the 'bundled' MinGW, right?
Because the 'about' windows show a MinGW path (the one I use for BMax).
I have also installed another MinGW version (in c:\TDM-GCC-64) (I don't remember why...)
I just tried to change the name of this folder (in _TDM-GCC-64) and now it seems I need to 'rebuild' all the modules...

It would be handy to output that inform what tool we are using (just the path I mean)


Derron(Posted 2016) [#29]
Because the 'about' windows show a MinGW path (the one I use for BMax)


MaxIDE does not ask "bmk" what MinGW will get used -- it also should hide "fasm" information when running an NG compiler-toolset.


@unhandled exception
So something within "New TWindowsGUIDriver" tries to access an object which is "null".

-> win32maxguiex.bmx
-> Method New()

And add some check what object is "null"/invalid before calling its methods/properties.


bye
Ron


Brucey(Posted 2016) [#30]
And this line in (win32maxguiex.bmx) is highlighted

Try a release build for now. It should be okay.


BlitzSupport(Posted 2016) [#31]
Print "Hello world" working here now!

I noticed it still failed to build again after making the changes, but unchecking Quick Scan and trying again sorted that.

Thanks!

EDIT: aaaand back on topic, I can build 32- and 64-bit MaxGUI programs, which is awesome. Great work, all!


degac(Posted 2016) [#32]

Try a release build for now. It should be okay.


Yes, I confirm it compiles without problem.


degac(Posted 2016) [#33]
Another error report:

MaxGUI, ProxyGadgets, CreateScrollPanel() example (from documentation).

Compiling I got an error (can't find interface for module 'bah.gtkmaxgui') and the file blitz.release.win32.x64.i has this
...
OnDebugLog(message$)&=mem:p("bbOnDebugLog")
AppDir$&=mem:p("bbAppDir")
AppFile$&=mem:p("bbAppFile")
AppTitle$&=mem:p("bbAppTitle")
AppArgs$&[]&=mem:p("bbAppArgs")
LaunchDir$&=mem:p("bbLaunchDir") '<<<<<<<<< this line is highlighted


HyperLink and Splitter proxygadgets are working without problems.


Brucey(Posted 2016) [#34]
I've fixed the imports, and pushed it back into github.


degac(Posted 2016) [#35]
Another error report


This is a proxygadget I've created. I commented out some elements not needed (I believe) here.

When I recompile modules I got the following error
Unable to find overload for clientwidth(Tgadget)

Probably my implementation of Proxygadget is not perfect, but I have no idea where I can fix my source code to bypass this.
I have another one proxygadget (a DatePicker, that use another one proxy - Calendar) and I got the same error on ClientWidth().
A SpinnerGadget proxy (written by JoshK) has problems with knob/conversion value - the value is shown in a textfield - I need to check where the 'value' is lost.
I know it's a first implementation of MaxGUI 'rewritten' inside to be 64-compliant, and I have no hurry for these errors!


Brucey(Posted 2016) [#36]
Tha latest bcc (in github) fixes that issue.
That problem was that it was accepting a partial match on the method ClientWidth(), then failing it for the wrong parameters, rather than widening the scope to see if there were any other functions of the same name.

Whenever you update bcc, you should always do a full rebuild of everything. :-)


degac(Posted 2016) [#37]
Ops, sorry, I didn't notice you already answered to my first error report!
Wow, it was the first of the year, take a breath :D!

Thank you!


degac(Posted 2016) [#38]
I confirm that the latest BCC release fixes all the bugs reported above.

ps:

I noticed that SetGadgetPixmap() doens't guarantee results. Sometimes I can see a pixmap, often I can see nothing.

I have tested with some .png I use, I don't find any special difference in them (saving options or other things).
Any PANELPIXMAP_XXX combination tested, no differences.


Brucey(Posted 2016) [#39]
I noticed that SetGadgetPixmap() doens't guarantee results.

Interestingly, I've noticed this across all three MaxGUI platforms. I believe it's something to do with the alpha channel on 32-bit pngs. Converting to 24-bit usually solves the problem.

I didn't have time yet to solve the problem myself though... source is there for anyone who likes a challenge! ;-)


Dabhand(Posted 2016) [#40]
Just to note... If anyone builds and runs a NG Windows MaxGUI app and receives a

"ANOMALY: meaningless REX prefix used"

message in the output pane when shutting the app, it's perfectly harmless, but to stop it, you need to uninstall AMD's [pointless] Raptr/Gaming Evolved app! :)

Worked for me!

Dabz


Brucey(Posted 2016) [#41]
I noticed that SetGadgetPixmap() doens't guarantee results

That should be working now with the latest Win32MaxGUIEx.


degac(Posted 2016) [#42]
Incredible!
Many thanks!
Just to know, what was the problem with the alpha-info in PNG?
I tried to look at the source code this week-end, but to be honest it was beyond my skill!
I found that a parameter (_alpha) was true, so somewhere the information about the .png I suppose was right when it was loaded.
But - excluding this - finding if the problem was in the drawing or elsewhere is a big black hole!


Derron(Posted 2016) [#43]
Think this was wrong:
https://github.com/bmx-ng/maxgui.mod/commit/3ab78e73f2c3738c91518541b27568058824ba1c

So he seems to have switched the blend-function-color-thing from RGBA to ARGB.


bye
Ron


Brucey(Posted 2016) [#44]
No, that's not RGB anything. It's a BLENDFUNCTION struct. :-)


Derron(Posted 2016) [#45]
Ok, then you mixed:
BYTE BlendOp;
BYTE BlendFlags;
BYTE SourceConstantAlpha;
BYTE AlphaFormat;


Seems that function likes premultiplied alpha ... so if that is somehow not done, you might see some visual glitches.
-> https://msdn.microsoft.com/en-us/library/windows/desktop/dd183393(v=vs.85).aspx


bye
Ron


JoshK(Posted 2016) [#46]
It will take me a while to get running but I will definitely try this out. Thank you.


Bobysait(Posted 2016) [#47]
Just installed the NG thing, seems pretty cool.

I had to make several changes in my modules to get every thing to compile
Lots of "returns is void extected int" on overriding methods and some int vs byte ptr stuff ... but, finally it does work.

though, I can't compile my application because of it keeps telling me there's a missing "," at "pCallBack(o:TActionHandler)"


Building MDT_EDITOR_V0.1
[ 91%] Processing:GUI_SCENE.bmx
[ 92%] Processing:TInputFilter.bmx
[ 92%] Processing:UI_Material.bmx
Compile Error: Syntax error - expecting ','.
[E:/HD_DEV/Indie/mdt_corp/Tools/MDT_EDITOR/import/TInputFilter.bmx;50;0]
Build Error: failed to compile (-1) E:/HD_DEV/Indie/mdt_corp/Tools/MDT_EDITOR/import/TInputFilter.bmx
Process complete




The function declaration is this one ... there is nothing missing.
Function Create:TActionHandler( pLayer:Int, pSource:Object, pEventIDs:Int[], pDatas:Int[], pReturnEventId:Int=0, pCallbackTests:Byte(o:TActionHandler)[], pCallBack(o:TActionHandler), pMode:Byte=ONACTION_QUIT, pName:String="" )


This function is supposed to use function pointers as argument, so maybe the NG version need a specific way to declare this ?


[edit]
Damned, I didn't post on the good topic ...
My bad, I have too many windows opened on the NG's topics


Brucey(Posted 2016) [#48]
If you are a github user, posting problems there can help : https://github.com/bmx-ng/bcc/issues

Or if not, a very simple, replicable example will speed up the process too.

Thanks :-)


Bobysait(Posted 2016) [#49]
Sorry, I'm not a github user ... but if required, I'll create an account.

Actually, I just realized we have to declare function pointers as "byte ptr".
Function Create:TActionHandler( pLayer:Int, pSource:Object, pEventIDs:Int[], pDatas:Int[], pReturnEventId:Int=0, pCallbackTests:Byte Ptr, pCallBack:Byte Ptr, pMode:Byte=ONACTION_QUIT, pName:String="" )

This works. (or at least, it does not halt the compilation here ... I need to get the full project to compile to know if it actually works or not)



ATM, I think there is maybe no error to post, it's probably the normal behavior regarding the fact function pointers are pointers ... (makes sense)
I keep on trying to compile my program, fixing bugs here and there (not real bugs, just incompatible stuff)
When done, I'll get back and give feedback ;)



[Finally] : I'll make an account to yell a bit about the MaxIDE :p
Ctrl+Arrow (left/right) switch between opened tabs ... that's really annoying when coding (it should move the cursor from between words) but I know it's already the way it works in the original MaxIDE (that was the reason I moved to Blide long time ago... this and ... no line numbers).
But, I won't yell, just kidding :)


Derron(Posted 2016) [#50]
@MaxIDE and Ctrl+Arrow

File -> IDE Settings -> "Use OS Specific Shortcut Keys"



bye
Ron


xlsior(Posted 2016) [#51]
Correct me if I'm wrong, but wouldn't using Int for pointers still cause issues when compiling to 64-bit? (the program It could conceivably run on a memory location >4GB, overflowing the int?)


Bobysait(Posted 2016) [#52]
@Derron : Thanks, that was not implicit enough for me and my little brain :)

I had an issue with maxgui that failed with a Null object just running this

Import maxgui.drivers


it seems that the problem was here (while initializing probably something like the desktop gadget which has no parent ?)
	Method QueueResize( hwnd:Byte Ptr, xpos, ypos, width, height )
-->>>		If parent And GetParent_(hwnd) = parent.Query(QUERY_HWND_CLIENT) And TWindowsGadget(parent).hdwpStruct Then	

whether or not parent is null "parent.Query(QUERY_HWND_CLIENT)" is evaluated and produice an error.

I solved it by separating the 2 checks
If parent
	If GetParent_(hwnd) = parent.Query(QUERY_HWND_CLIENT) And TWindowsGadget(parent).hdwpStruct Then

So, correct me if I'm wrong, but doesn't bmxNG have a different behavior than bmx origin (sounds like a xmen movie title -_-')
-> the second condition should not be evaluated if the first condition is false


[EDIT]
After some troubles, I finally get it working !
It's not stable with random crashes on the compiled exe, but it's a start.

Also, already mentioned, but yeah, gadgetpixmap doesn't work.
-> the whyte squares are supposed to preview from the materials and textures from the scene.

>> CLICK ME << big image that break the forum formatting ... So, This is just a link to the image
(maxgui stuff with my glsl 3d engine working on it)


Bobysait(Posted 2016) [#53]
Got the pixmap working by ... formatting the pixel ... format
SetGadgetPixmap(Self.view, ConvertPixmap ( l_renderedTex.getPixmap(0, True), PF_RGB888 ) )

@Self.View is the panel of the thumbnail, @l_renderedTex is a the framebuffer GL_COLOR_ATTACHMENT0 from the rendered buffer and the method getPixmap returns the bitmap data from the video memory and convert it to a PF_ARGB8888 pixmap

So, a more generic formula :
If pixmap.format<>PF_RGB888
SetGadgetPixmap ( gadget, ConvertPixmap (pixmap, PF_RGB888) )
Else
SetGadgetPixmap ( gadget, pixmap )
Endif


-------------------------------------------------------------------

Then, a maxgui bug happens (as you can see here on the screenshot )
the scrollbar doesn't update correctly.





Do I need to post a github issue message for this ?


Brucey(Posted 2016) [#54]
Got the pixmap working by ... formatting the pixel ... format

This should be working with the latest source.

the scrollbar doesn't update correctly.

That may be an issue.

If you can give a small example please, that would help :-)


Bobysait(Posted 2016) [#55]

This should be working with the latest source.



It was the latest package from the bmx-ng (BlitzMax Win32 v0.70.3.09)
> https://github.com/bmx-ng/bmx-ng/releases



If you can give a small example please, that would help :-)



I will try to reproduice it in a small example.
But it's maybe just me who doesn't use it in the good way ...


Brucey(Posted 2016) [#56]
yes, I said "source". The source in github is newer than the release :-)

I will try to reproduice it in a small example.

Thanks.


Bobysait(Posted 2016) [#57]
Damned ... while trying to make a sample, I ran into another problem

Splitter (from maxgui.proxygadgets) generates an unhandled exception



PollEvent/WaitEvent fail on the splitter handle only with debug enabled


Brucey(Posted 2016) [#58]
Well, that was hard to track down.

In the end, it turns out that there is an problem with my bcc ignoring "nodebug" on functions.

The actual issue itself is in MouseProc() in win32maxguiex.bmx. This is the array in question :
Global intButtonStates%[3]

And here's some example code using it :
If intButtonStates[MOUSE_MIDDLE] Then wp:|MK_MBUTTON


And just for interest, here's a reference to keycodes.bmx :
Const MOUSE_LEFT=1
Const MOUSE_RIGHT=2
Const MOUSE_MIDDLE=3


Anyone see any problems here?

Answers on a postcard to....

:-p


BlitzSupport(Posted 2016) [#59]
Guessing MOUSE_LEFT | MOUSE_RIGHT = MOUSE_MIDDLE is a problem?


Chalky(Posted 2016) [#60]
.


col(Posted 2016) [#61]
I'd think more than likely the array out of bounds is an issue, but that's also still a valid point with the mouse button consts. 'point' get it? mouse pointer... point OMG what have I been drinking :-)


Derron(Posted 2016) [#62]
@BlitzSupport:

The intButtonStates array has a length of 3... so
IntButtonStates[0/1/2]
Is valid. But the mouse button constants are 1/2/3 . So a hit with mouse button 3 leads to an segfault. As "nodebug" was just...this wont get "found" when debugging your app.

Bye
Ron


Brucey(Posted 2016) [#63]
So a hit with mouse button 3 leads to an segfault

Well, the result is undefined.
But generally you don't want to access memory outside of your variables :-)


Derron(Posted 2016) [#64]
ok... might lead to a segfault :-)

Code should have a "arr[mousebutton -1]" or so - but even this is far from perfect as it relies on "mousebutton"-constants (keycodes.bmx) to not change (eg to 0 or to 10).

bye
Ron


Bobysait(Posted 2016) [#65]
with the Updated sources, bugs on the splitter and pollevent/waitevent are corrected.

BTW : Great version, a very good job on this, and it works almost like a charm (still some bugs here and there, like the For loop on type members) but, IMHO, it suffers from a missing explicit "How To instal" for the whole process, and the readmes should be more visible.

Actually, I must say I was a bit confused while searching the process to instal blitzmax NG from scratch.
Make a fresh instal of blitzmax from the original pack (the "real" blitzmax from this site), set the environment variables to blitzmax path and mingw (if required)
Download all the stuff from the bmx-ng trunk (brl, pub and maxgui modules (+ optional other modules), the bmx-ng itself, the bmk and bcc, the new maxide) then run the blitzmax "vanilla", build bmx, bcc, and maxide with it, copy compiled bmx, bcc exes + make and core to the bin dir, copy all the maxide stuff (exe + all the rest ? I copied all ... but I'm pretty sure it just needs one or two files) in the root directory of blitzmax, copy mingw32 from the bundle (I put it in blitzmax root dir for convenience, I suppose it could have been in C:\ directly), copy/paste the ported versions of the modules to the mod directory, and finally set the environment variables for blitzmax (if it's all copied on a new blitzmaxNG directory) and the path to mingw32 ...
Oh, and I forgot, the last part : compile all modules ^_^ which can take several minutes (took me 30/45 minutes to compile modules in thread/non-threaded / x86 / x64 ), but this step is easy ! boring ... but easy.

Sorry to have to say that but, that's really not user-friendly.
Just hope it will be, else potential users will just be afraid just by installing it. (We all know how windows users are made to be lazzy with this kind of stuff ... Windows always do the best to make every thing for you that users just become stupid)

ps : BTW, it could be nice to have a "build module" option that runs the x86 then the x64 (thread and non-thread). It would take time, but at least I could take a coffee while it builds everything. ATM, we need to come back each time to run the process again for each target and acrhitecture.


Brucey(Posted 2016) [#66]
Well, once things settle down and the releases become more stable, you shouldn't need to think about installing it from scratch (you don't install the original BlitzMax from scratch either :-)

With the MinGW32 folder in your BlitzMax folder, bmk will locate that and use it in preference to *any* environment variables you have configured. The idea behind this is that you shouldn't need to be messing around with your environment to build some BlitzMax code.
Another feature of this is that you can have several different instances of BlitzMax each with their own local copy of MinGW (perhaps different versions), and none will accidentally try to use the wrong version of MinGW.

30/45 minutes is nothing. You should try rebuilding wxMax ;-)

As I say, for most users, you should only ever need the latest release - and not need to fetch/install any separate parts of it.


Derron(Posted 2016) [#67]
If you are a _developer_ you will not be afraid of having such a "huge" installation instruction list...

Once things settle down a bit the releases surely might be self-contained. Even now you do not need to manually compile all modules, as the Brucey made the tools clever enough to check on their own whether modules need a (re-)build.

This also solves your "x86 then the x64"-build-idea.


So how would I build the newest one:
- fetch a prebuild package from bmx-ng.com
- fetch the latest bcc/bmk, compile both of them and place the binaries in BMXNG/bin
- fetch the latest module code (brl, pub, your-other-modules)


Once the modules work similar to vanilla (means "only a few bugs") the whole module/bcc/bmk-source fetching could get skipped. If vanilla bmx got improved, you would have to follow similar steps (fetching, recompiling).... only difference is, that you need MinGW instead of FASM.exe


But you are right -- it maybe needs some more "love" regarding that "setup_install.script" (as it is not Windows-friendly :-)).

Dabhand offers a windows tool already which solves the task. Think he might adjust his code to skip "git" (not needed if you download the zip files, which already are cleaned from .git-files).

A corresponding Tool (written in BMX) could be written very fast (fetching and executing processes) but somehow _I_ like scriptfiles (".bat" in Windows) more.


bye
Ron


Bobysait(Posted 2016) [#68]
Sure it would (it will !) be handy :)

For the 30/45 minutes, I know it's not that big and I've got no problem with that, but here is the weird thing behind this :
It takes more time to build the modules than downloading all the compiled version for all the targets as "already compiled binaries"
With a midle-range bandwith it's a matter of 15 minutes to download 200-300 Mo, while it takes more than half an hour for a 3/4 GHz Machine.
Maybe we should provide a fully compiled pack of blitzmax available on some free servers ? it would saves a bunch of time.

But I assume that it's just my lazzy-windows-brainwashed-spirit that want this kind of feature ^_^


Derron(Posted 2016) [#69]
Your precompiled-modules are then compiled with which version of MinGW? What happens if the dev-user wants to use another MinGW? - He has to recompile all modules.

Dunno why recompilation took soooo long on your computer. Did you compile "bmk" in threaded mode ? (threaded c-compilation speeds up the process).

I just rebuild x86 in release and debug (bah.mod with gtk-thingies, brl.mod, pub.mod and sdl.mod):
$ time ./bmk makemods -a

real	1m18.416s
user	2m44.762s
sys	0m18.352s



My system is an aged AMD Llano 4 core - running on an sooner-or-later-dying SATA-HDD (no SSD yet).

Most time is consumed for file lookups when compiling your project - which is why Brucey added the -quick param to bcc/bmk which skips such "is the imported module code changed?"-checks.

I have to confess, when running my "compile for windows"-VM (single core, limited to 50% cpu usage, 512MB RAM, virtual HDD) the compilation of modules takes a while ... mostly this is because of the virtual HDD (time decreases when doing some virtual-LAN-compilations). So "MinGW" might indeed be a bit slowe ... but 45 minutes?


@Free Servers
It is free (open source) software - so you might just create a github.com repository and some releases their (each release can hold up some files - so packages for Win, OSX, Linux...). Downloads are then coming from AWS or another CDN - no traffic issues for poor server owners.



bye
Ron


Bobysait(Posted 2016) [#70]
the full (debug+release for both x86 and x64 and both non-threaded and threaded) rebuilt took 40 minutes, but Each pass took around 8-12 minutes (for release+debug)
So 4 pass (x86 / x64/ x86mt / x64mt) is around 4*10 minutes

Actually my cpu is pretty good (AMD phenom II x6 at 3 Ghz)
Not the best, but still does the job very well.
It's just that I rebuild all possible targets for all possible architectures once, then I'm done with native modules.


BlitzSupport(Posted 2016) [#71]
I think it's worth repeating that you don't need to rebuild all with NG, as it just builds whatever modules it needs on-the-fly whenever you try to compile your own programs.


Bobysait(Posted 2016) [#72]
yep, I know that it's not required, but I really prefer having everything done once, than "on the fly" having to wait minutes just to compile a simple sample because of some not "yet compiled" modules.
Once it's done, it's done :)


xlsior(Posted 2016) [#73]
I have needed to do a rebuild all with NG myself the other day: after one of the updates it stopped drawing any graphics to the screen until I manually rebuilt all modules, and then it worked fine again.


Brucey(Posted 2016) [#74]
There are still some core changes being made (like for example to arrays). Such changes do require a full rebuild, otherwise parts of your application may become out of sync with the modules. :-)

Generally this would not be an issue with a stable code-base, and the build-as-required strategy would work as expected.


BlitzSupport(Posted 2016) [#75]

I really prefer having everything done once, than "on the fly" having to wait minutes just to compile a simple sample


Fair point!


eagle54(Posted 2016) [#76]
Hi, I have a problem with this example :

SuperStrict

Import maxgui.drivers

Global window:Tgadget

window=CreateWindow(AppTitle,100,100,400,400,,WINDOW_TITLEBAR|WINDOW_CENTER|WINDOW_RESIZABLE)

Global panel1:Tgadget=CreatePanel(10,10,227,227,window)

SetGadgetColor panel1,0,100,255

Global img_panel:TImage = CreateImage(2, 2)
Global pix_panel:TPixmap = LockImage(img_panel)

'create green tile map
WritePixel(pix_panel, 0, 0, $ff00ff00)
WritePixel(pix_panel, 1, 0, $ffffffff)
WritePixel(pix_panel, 0, 1, $ff00ff00)
WritePixel(pix_panel, 1, 1, $ffffffff)

UnlockImage(img_panel)

SetGadgetPixmap panel1,pix_panel,PANELPIXMAP_TILE

While True

WaitEvent

Select EventID()

Case EVENT_WINDOWCLOSE
End

End Select

Wend

I have no pixmap displayed with x86 windows (It's good for x64 win, ... not tested with Linux, MacOS, ... )

Could you verify this little piece of code?

Many thanks


Derron(Posted 2016) [#77]
64bit linux seems to run ok too.



bye
Ron


Brucey(Posted 2016) [#78]
This example works okay for x86 using the latest MaxGUI source from github.


eagle54(Posted 2016) [#79]
I use Bmx-ng version : BlitzMaxNG_win32_Unoffical_0_71.7z (downloaded from http://www.bmx-ng.com/main/downloads/)

Yesterday, i've downloaded all updates from https://github.com/bmx-ng/, and rebuilt the essentials (bcc, bmk, brl, pub, maxgui). When i rebuild mods, i rebuild all mods with bmk (debug, release, multithreaded -> no error)

The last maxgui.mod was updated 27 days ago from github, and if i test now, i've always the same problem with x86 windows.

What's wrong with bmx-ng? I don't understand


markcw(Posted 2016) [#80]
eagle54, I just tested your example in win7 both x64 and x86 with debug and release and pixmap displays fine all times. I have bcc -v 0.72 and tdm gcc 4.8.1.


eagle54(Posted 2016) [#81]
bcc version used v0.73 (latest), gcc 5.1 (BlitzMaxNG_win32_Unoffical_0_71)

Ok, i will see later ... I think rebuild all and i'll test again

So, thanks for your help Derron, Munch and Brucey


grable(Posted 2016) [#82]
Why not try Frisky from that bmx-ng site? It downloads everything needed with GIT, you cant get fresher than that ;)


eagle54(Posted 2016) [#83]
i didn't know Frisky, but if it can download packages and update bmax-ng from Github, it's a good idea. Thanks for your answer.


eagle54(Posted 2016) [#84]
I've resolved my problem with bmx-ng :)

I've compiled my piece of code with tdm64-gcc-4.8.1-3 and it's OK for win-x86 and win-x64 architecture (my computer : Win7 x64 with last updates bmx-ng ...)

Be carefull with tdm64-gcc-5.1.x, perhaps, you'll meet some trouble

Thanks Munch, you're right for tdm64-gcc-4.8.1 ;)


eagle54(Posted 2016) [#85]
I have a problem with API Window, i can't compile this example with bmx-ng (bcc v0.73, last updates, tdm64-gcc-4.8.1-3) :

SuperStrict

Extern "win32"
  Function MessageBoxW(hwnd%, lpText$w, lpCaption$w, uType%) 'UNICODE ...
EndExtern

'main
Const ICON_INFO% = $00000040 'Icon Info ...
MessageBoxW(0, "This is my Test", "Bmx-ng App", ICON_INFO)
End


I've tested with the (old) official Bmax v1.5x (TDM GCC 4.7.x), and it's OK. Some APIs won't compile with bmx-ng. Any suggestion (i don't want to use 'Notify' command Bmax)?.
Thanks in advance.


Derron(Posted 2016) [#86]
So what was the error string you got?


bye
Ron


markcw(Posted 2016) [#87]
I tested eagle's pixmap example with tdm 64 gcc 5.1.0 and confim it doesn't work for x86. It just draws a blue square instead of lines. The error in debug/release is:

Warning: resolving _AlphaBlendArgs@44 by linking to _AlphaBlendArgs
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups



markcw(Posted 2016) [#88]
Also, testing with tdm 32 gcc 5.10 in legacy Bmx, eagle's example works in debug but EAV's in release.


eagle54(Posted 2016) [#89]
@Derron : I can't compile API MessageboxW (for Windows platform only ...).

Build Error Bmx-ng (on Win7 x64, tdm64-gcc-4.8.1-3, bcc v0.73, last packages bmx-ng downloaded on Github) :

Building test6
[ 99%] Processing:test6.bmx
[ 99%] Compiling:test6.bmx.gui.release.win32.x86.c
In file included from C:/BlitzMax/samples/GUI/.bmx/test6.bmx.gui.release.win32.x86.c:1:0:
C:/BlitzMax/samples/GUI/.bmx/test6.bmx.gui.release.win32.x86.h:38:24: error: conflicting types for 'MessageBoxW'
extern void __stdcall MessageBoxW(BBINT bbt_hwnd,BBSHORT * bbt_lpText,BBSHORT * bbt_lpCaption,BBINT bbt_uType);
^
In file included from c:\blitzmax\mingw32\x86_64-w64-mingw32\include\windows.h:72:0,
from C:/BlitzMax/mod/brl.mod/blitz.mod/blitz_thread.h:7,
from C:/BlitzMax/mod/brl.mod/blitz.mod/blitz.h:28,
from C:/BlitzMax/mod/brl.mod/blitz.mod/.bmx/blitz.bmx.release.win32.x86.h:4,
from C:/BlitzMax/samples/GUI/.bmx/test6.bmx.gui.release.win32.x86.h:4,
from C:/BlitzMax/samples/GUI/.bmx/test6.bmx.gui.release.win32.x86.c:1:
c:\blitzmax\mingw32\x86_64-w64-mingw32\include\winuser.h:3012:25: note: previous declaration of 'MessageBoxW' was here
WINUSERAPI int WINAPI MessageBoxW(HWND hWnd,LPCWSTR lpText,LPCWSTR lpCaption,UINT uType);
^
Build Error: failed to compile C:/BlitzMax/samples/GUI/.bmx/test6.bmx.gui.release.win32.x86.c



Some APIs window generate errors during the build, example :

Extern "win32"
Function RegOpenKey:Long(hKeyParent:Int,SubKey$z,phkResult:Byte Ptr)="RegOpenKeyA" '-> Build Error
EndExtern


And others ....-> It's OK
Extern "win32"
Function RegFlushKey:Long(hKey:Int)="RegFlushKeyA" '-> Build OK
EndExtern


I don't know if there're many APIs Win impacted by this problem, perhaps a bug ...


@Munch : Yes, I confirm the 'Blue Screen win-x86' too, perharps a 'tip' to test TDM-GCC 5.1.x Package with Bmx-ng (it runs OK for tdm64-gcc-4.8.1-3) :)

Thanks for your help


eagle54(Posted 2016) [#90]
I read this post ( see above) : http://www.blitzbasic.com/Community/post.php?topic=105537&post=1287314

But i use x86 Win architecture only (not x64) ... see later ....


eagle54(Posted 2016) [#91]
-


markcw(Posted 2016) [#92]
Also, testing with tdm 32 gcc 5.10 in legacy Bmx, eagle's example works in debug but EAV's in release.

Sorry this is a mistake, I rushed testing and I don't think I rebuilt my mods as the EAV happened with all tests.

So to confirm the pixmap example (and anything else I tested) worked in debug/release using tdm 5.1.0 32 with a modified legacy Bmx which is good news.

This was after using bcc, bmk and FASM found in OS Bmx (I've yet to build those I just copied them and it worked). I was getting fatal errors (undefined references to blah) until I replaced those, legacy bcc is built with gcc 4.6.1.

Also make sure you copied the lib folder with the batch file. There's also a libunicows.a in OS Bmx because that was the one lib file dropped from tdm 4.7.1 up.


eagle54(Posted 2016) [#93]
Sorry this is a mistake, ...

Ok, no problem, sometimes it's very difficult to test everything (official BMax, bmx-ng crossplatform, ...), i understand :)

There's also a libunicows.a in OS Bmx because that was the one lib file dropped from tdm 4.7.1 up

Sure! Otherwise you can't build your App (i.e : OpenB3D) with TDM GCC 4.7.x and legacy Bmax 1.50 Win. I've no problem with Legacy Bmax, but just some little problems with bmx-ng ... :)


eagle54(Posted 2016) [#94]
Have you any suggestion about this error on bmx-ng ?

http://www.blitzbasic.com/Community/post.php?topic=105537&post=1295678

http://www.blitzbasic.com/Community/post.php?topic=105537&post=1295675

Thanks in advance.


Brucey(Posted 2016) [#95]
See this post for the solution.

Summary: you will need to create a file with .x suffix, with same name as the one containing your extern, and populate it with your externed functions.

Also note that hwnd is a pointer, not an Int - if you intend to use your code on 64-bit.


grable(Posted 2016) [#96]
you will need to create a file with .x suffix, with same name as the one containing your extern, and populate it with your externed functions.
This will break a lot of old code though :/

Couldnt you shadow it with another function but make it inline instead?
Extern "C"
  Function puts:Int( s$z)
EndExtern
extern inline int bb_puts( const char* s) { return puts(s); }
And for private functions
static inline int bb_puts( const char* s) { return puts(s); }
Perhaps even using __attribute__((always_inline)) to make sure it gets inlined (mostly).

EDIT: Hmmmm.. when i think about it, this would cause problems if comparing the address of these to the originals though. But i dont think that happens too often.
EDIT2: The more i think about this, the more i realize its a rats nest ;) The compiler would have to know which symbols were previously defined, which is a daunting task (parsing headers and caching all the symbols). And if your doing that, you could just as well use the original.


Derron(Posted 2016) [#97]
Another option would be...that the compiler (bcc) spits out help on how to solve the issue (possible entry of such an .x-file.

As the error is created from GCC and not BCC it seems that BMK would have to evaluate the GCC output then (previously defined in xyz) and then asking BCC for help on line xyz of file x.

Would that even be possible?


Bye
Ron


Brucey(Posted 2016) [#98]
[quote] And if your doing that, you could just as well use the original. [/quote
Indeed :-)

The issue only arises if a header (say, windows.h) is included somewhere up the chain (in this case, brl.blitz does) and your code happens to extern a function from it.
If the parameters don't match, modern gcc's will complain.
In which case, creating a .x file, and adding the appropriate declaration in it seemed like the least effort. Your code is still compatible with old BlitzMax, as all you've done is add a file that is ignored by it.

When NG's bcc is processing extern functions, it just does a lookup against the file. If your function is there, it can decide whether to declare it in the generated header or not (based on the presence of an exclamation at the end of the line).

It's not particularly pretty, but it was a path I took that required the least amount of work.

As I usually say, NG is about 99% high-level BlitzMax compatible, but when you start doing low-level stuff, like directly accessing APIs, the end-user may need to do some more work.

I think for the benefits you can gain from NG (as you've seen recently in that multi-thread perlin example), the extra work a user may need to perform (for low-level stuff) may be worth it.


grable(Posted 2016) [#99]
Sure, if BCC maps the generated C line of each extern definition it could parse the error messages and figure this out.
But it would still have to build a table of all these, and i imagine it could be rather slow if it had to do multiple round trips to compile a few files.
And it would have to cache these symbols too, which might speed things up over time. But then have to deal with cache invalidation on changed files and all that jazz.

A pain in the ass im sure ;)


Derron(Posted 2016) [#100]
It only should need to build a table once it run into an error. So if it compiles flawless - no problem, but if there is such an multiple-definition-error, then it (= BMK) triggers BCC again with additional parameters so BCC runs the "extra portion of workload" this time.

If you want avoid this, we could think about adding a "helper" binary (like "LINT") which does these checks (could even be extended to check for unused variables and so on).


Edit:
The reason why I "request" such a feature is, that I am not able to create the needed .x-files to get maxmod2.mod to compile (you know...streaming ogg audio, a feature which I request for a long time now :-)). Somehow my brain is just not capable of doing it on my own (I know, I just did not try hard enough). Maybe more complex examples would help (I am sure there is an easy "step-by-step" variant possible).



bye
Ron


eagle54(Posted 2016) [#101]
@Brucey : Sorry, i am a bit confused, ... lot of posts here... :o(

Well, ok, i created an x file (with my function and types)

test6.x :
int MessageBoxW(HWND, LPCWSTR, LPCWSTR, UINT)!

and my bmx file (the same name as x file) :

test6.bmx :
SuperStrict

Extern "win32"
  Function MessageBoxW%(hwnd%, lpText$w, lpCaption$w, uType%) 'UNICODE ...
EndExtern

'main
Const ICON_INFO% = $00000040 'Info ...
MessageBoxW(0, "This is my Test", "Bmx-ng App", ICON_INFO)
End

I tested, it's Ok for x86
Building test6
[ 97%] Processing:test6.bmx
[ 98%] Compiling:test6.bmx.gui.release.win32.x86.c
[100%] Linking:test6.exe

Process complete

And .... It's Ok for x64
Building test6
[ 97%] Processing:test6.bmx
[ 98%] Compiling:test6.bmx.gui.release.win32.x64.c
[100%] Linking:test6.exe

Process complete


Tested with config : Bmx-ng (on Win7 x64, tdm64-gcc-4.8.1-3, bcc v0.73, last packages bmx-ng downloaded on Github)

@grable :
This will break a lot of old code though :/

Yes, it's a little bit different between legacy BMax and BMX-NG. May be, it's more difficult to implement with bmx-ng, i don't know.

Many thanks for your help, i hope that this example for bmx-ng will help other people, here.


Brucey(Posted 2016) [#102]
This is wrong for 64-bit compatibility:
Function MessageBoxW%(hwnd%, lpText$w, lpCaption$w, uType%)

It needs to be:
Function MessageBoxW%(hwnd:Byte Ptr, lpText$w, lpCaption$w, uType%)

Although in your particular use of it you are setting the argument to 0, if you ever wanted to use your version with an actual window reference, it would probably crash on 64-bit.

To be on the safe side, disregard *everything* you've seen regarding the implementing of Ints as pointers in BlitzMax, and always use pointers instead. (this may require "fixing" third party code)


eagle54(Posted 2016) [#103]
To be on the safe side, disregard *everything* you've seen regarding the implementing of Ints as pointers in BlitzMax, and always use pointers instead. (this may require "fixing" third party code)

I didn't use windows Handle (HWND -> 0), so, i'll be carefull with x64 win.

Thanks for your help Brucey.


eagle54(Posted 2016) [#104]
Another test (3 files) ...

My header file : myvars.bmx
Const title$   = "My App"
Const version$ = "Version XYZ"
Const author$  = "~nWritten by Me" 'carriage return added -> ~n
Const ICON_INFO% = $00000040 'Info ...

My x file : test8.x
int MessageBoxW(HWND, LPCWSTR, LPCWSTR, UINT)!

My bmx file : test8.bmx
SuperStrict

Import "myvars.bmx"

Extern "win32"
  Function MessageBoxW%(hwnd:Byte Ptr, lpText$w, lpCaption$w, uType%) 'UNICODE ...
EndExtern

'main
MessageBoxW(0, title + " " + version + author, title, ICON_INFO)
End

Build OK (x86 and x64)
Building test8
[ 94%] Processing:myvars.bmx
[ 95%] Compiling:myvars.bmx.release.win32.x86.c
[ 97%] Processing:test8.bmx
[ 98%] Compiling:test8.bmx.gui.release.win32.x86.c
[100%] Linking:test8.exe

Process complete

Tested with config : Bmx-ng (on Win7 x64, tdm64-gcc-4.8.1-3, bcc v0.73, last packages bmx-ng downloaded on Github)


But, ... but, ... :o), when test8.exe is running, my MessageBox doesn't display correctly author$ string (Problem with ~n -> <CR>, Carriage Return). I tested with 'Notify' BMAX, and it's the same thing (display error ...). What is the problem? Could you test this example if you have time (be carefull, it's for OS Windows only, WINAPI ...)?

Thanks in advance


markcw(Posted 2016) [#105]
CR doesn't work with Import "myvars.bmx" for some reason but Include "myvars.bmx" works. In OS Bmx you can use Import "myvars.bmx".


grable(Posted 2016) [#106]
@eagle54
If quick build is enabled, you can change the \n to ~n and it works.
So it seems to be a bug in the creation of the .i file. It converts string escapes to C style when it shouldnt.

And just so you know ~n is line feed and ~r is carriege return ;)


eagle54(Posted 2016) [#107]
@grable:
So it seems to be a bug in the creation of the .i file. It converts string escapes to C style when it shouldnt.

Yes, I also think that it's a bug.
And just so you know ~n is line feed and ~r is carriege return

True! You're are right (~n = 13 <LF>, ~r = 10 <CR>). So, if you open test8.bmx.gui.release.win32.x86.c, you have this concatenated string :
static BBString _s6={
	&bbStringClass,
	33,
	{77,121,32,65,112,112,32,86,101,114,115,105,111,110,32,88,89
	,90,92,-> 110 <-,87,114,105,116,116,101,110,32,98,121,32,77,101
}
To my mind, the value '110' should be '13' -> ~n. It's a mistake.
@munch:
CR doesn't work with Import "myvars.bmx" for some reason but Include "myvars.bmx" works. In OS Bmx you can use Import "myvars.bmx".

You can also replace 'Const author$' by 'Global author$', and ... it works ... but, you shouldn't modify. I think it's bug.


grable(Posted 2016) [#108]
True! You're are right (~n = 13 <LF>, ~r = 10 <CR>)
Not to be a total dick, but its CR=13 LF=10 :p

And your right, its not only the .I files but also the concatenated string. The reason for this is probably because it reads those strings from the .I files before it concatenates them. As the originals are correct.


Brucey(Posted 2016) [#109]
That should be fixed now.


eagle54(Posted 2016) [#110]
Thanks for your help grable, munch and Brucey ;)


eagle54(Posted 2016) [#111]
Hello, I meet 2 errors with bmx-ng

1) When i want to rebuild MaxGUI Mod, i have this error :
[ 93%] Processing:hyperlink.bmx
[ 94%] Processing:scrollpanel.bmx
[ 94%] Processing:splitter.bmx
[ 95%] Processing:win32maxguiex.bmx
Compile Error: Auto array elements must have identical types
[C:/BlitzMax/mod/maxgui.mod/win32maxguiex.mod/win32maxguiex.bmx;4759;0]
Build Error: failed to compile C:/BlitzMax/mod/maxgui.mod/win32maxguiex.mod/win32maxguiex.bmx
C:\BlitzMax\mod>

It's the same thing with Warning Flag On (Build Options)


2) An other trouble ....
Try to debug this example in MaxIDE (Debug Mode On) :
SuperStrict

Function Add%(a%, b%)
  Return a + b
End Function

DebugStop

Const _TEST% = 1
Global a% = 1
Global b% = 2
Local txt$ ="test"

Print "Add = " + Add(a, b)

End
Const & Global vars are not displayed in debug windows (MaxIDE), but local vars seem to be OK

Tested with config : Bmx-ng (on Win7 x64, tdm64-gcc-5.1.0, bcc v0.79, bmk 3.14, last packages bmx-ng downloaded on Github

Any suggestion about these errors ?

Thanks in advance


eagle54(Posted 2016) [#112]
Hi, all

See above my 2 problems #111 ...

1) PB 1:
If i modify win32maxguiex.bmx [Line 4759;0] :
Local Rect[] = [_item,0,0,0] -> Local Rect[] = [Int Byte Ptr _item,0,0,0]
build maxgui is OK. Is it an Auto Array issue (see GitHub about bcc issues ...) ?


2) PB 2:
I don't know about Const & Global vars (not displayed in debug windows in MaxIDE), local vars seem to be OK, i don't understand

If you've any idea ....


col(Posted 2016) [#113]
BlitzMax NG is kindof stricter is some ways than the legacy BMax, but only in the sense that the code needs to be 'more technically correct' that what the legacy compiler put up with.

Ref Globals and 'non local' Consts
It looks as though the debug data isn't being generated so that indeed tends to lean towards a bug.


eagle54(Posted 2016) [#114]
Ok, thanks for your answer col. I don't know if Mister Brucey reads theses posts (i hope ...) :)

So, i will be patient.

Many thanks


col(Posted 2016) [#115]
I'm sure he does eventually.
For NG bugs you will get a faster response if you post to the github repo.

Sometimes he replies and fixes things there so fast that I'm becoming convinced that he's not a human :D