MaxGUI Updates Discussion Thread

BlitzMax Forums/BlitzMax GUI Programming/MaxGUI Updates Discussion Thread

#1

I've moved all the MaxGUI update announcments over to a new worklog:

MaxGUI Updates *click*

Any future updates and enhancements will be posted there from now on, although a brief summary will be provided in the top few posts. It was too hard to keep the announcements separate from the discussions in the previous thread.

So, if you are a registered MaxGUI owner and want to get a hold of the latest MaxGUI modules, direct your SVN clients to...

~~http://blitzbasic.com:81/svn/maxgui/dev/~~ - The public BRL SVN server is no longer available.

Note: If you need help with downloading the new MaxGUI development modules from SVN, check out this thread *click*.

Latest Module Versions
Last Updated: 17th February 2008

MaxGUI.MaxGUI (v1.26)
MaxGUI.ProxyGadgets (v1.05)

MaxGUI.Drivers (v0.03)
MaxGUI.CocoaMaxGUI (v1.42)
MaxGUI.FLTKMaxGUI (v1.40)
MaxGUI.Win32MaxGUI (v1.43)
MaxGUI.Win32MaxGUIEx (v0.62)

#2

Latest Worklog Post:

After the big BlitzMax v1.30 release, I'd like to announce some more MaxGUI improvements.

First off, general maintenance:

MaxGUI.MaxGUI

> Changed LookupGuiFont()'s Linux default for GUIFONT_SYSTEM to FreeSansSerif.

MaxGUI.CocoaMaxGUI

> Fixed GadgetPrint() so that entire page is printed for HTMLViews, instead of just the visible region.

Next, I took some time to sort out some Windows 9X bugs.

MaxGUI.Win32MaxGUI

> System event hooks have now been fixed which allow BlitzMax timers to work alongside MaxGUI on Window 9X.

MaxGUI.Win32MaxGUIEx

> Fixed infinite message loop on Windows 9X.

The latter of the two fixes now allows you to use the new MaxGUI.Win32MaxGUIEx driver on Windows 9X by replacing Import MaxGUI.Drivers with:

Import "-lunicows"
Import MaxGUI.Win32MaxGUIEx

...at the top of your code.

This will enable you to compile Unicode MaxGUI apps that should run on the legacy ANSI Windows 9X platforms as well as the new Unicode Windows 2000, XP and Vista OSs. If you intend to run your apps on Windows 9X, you will need to include either unicows.dll with the EXE or the end-user must have MSLU installed. As Windows 2000 upwards already support Unicode natively, they don't require any of these additional files.

Obviously, this isn't the default behaviour for the platform; Import MaxGUI.Drivers chooses to use the older ANSI MaxGUI.Win32MaxGUI as the default. This is because the MSLU isn't perfect and does suffer from a few bugs or inconsistencies - it isn't flawless, but it may be useful to a few brave MaxGUI coders!!! It should be business as usual unless you are wanting to code multi-language apps for the older platforms.

Finally, there have been some much-needed attention for the official Linux MaxGUI driver:

MaxGUI.FLTKMaxGUI

> Fixed FL timers and therefore tooltips.
> EventExtra() now contains the selected item's extra object for tabbers.
> All right-clicks are ignored internally in FL_TEXTEDITORs.
> Added SetMaxWindowSize() support.
> Found and fixed glibc error originating from flRedirectView() in fltkglue.cpp.
> Swapped Fl_Select_Browser with Fl_Hold_Browser so that highlight remains after mouse button is released.
> Added EVENT_GADGETMENU for treeviews.
> Hacked Fl_X.cxx to fix file drag n' drop support.
> Added alpha-support for pixmaps on panels.
> Added tab text alignment in the status bar similar to Win32, GTK and Cocoa.
> Added support for windows without the WINDOW_TITLEBAR flag.
> Added support for the TEXTFORMAT_BOLD and TEXTFORMAT_ITALIC flags in Text Areas.
> Fixed EVENT_GADGETACTION on text-areas/text-fields.
> Fixed gadget filter key codes, so that the tab key sends the correct data.
> Fixed (somewhat) active panel events and attempted to eliminate double firing.
> Imporoved toolbars.
> Switched to GTK+ FLTK theme, and removed black tabs and yellow highlighting.
> Fixed a glibc error in Fl_Text_Display.cxx.
> Fixed Fl_HelpView image freeing crash with broken_image substitute.
> Changed Fl_Panel so that it uses FL_NO_BOX, and fixed XGetImage crash in Fl_x.cxx.
> Swapped out source code for FLTK 1.1.9.

All available right-now from the MaxGUI SVN. ;-)

#3

Thanks again for all the work you put into this!
Can't say this too often!

If you need help with testing this "canvas speed issue", let me know! Still I think this is an user error. But who can tell without some source code? :(

#4

Thanks again for all the work you put into this!
Can't say this too often!

No probs, just as long as I know people appreciate it... ;-)

Your BETA testing is invaluable, especially your perseverance if something goes wrong and we have to start debugging. The modules would be a in a far worse state when released without your contributions.

If you need help with testing this "canvas speed issue", let me know! Still I think this is a user error. But who can tell without some source code? :(

Yep, wish he could send me something runnable... I think the phrase "Help me to help you!" is appropriate here...

#5

Thank you VERY much. Your hard work is really appreciated.

#6

Hi Seb,
the GadgetClass of Menu gadgets are always set zero, so i can't filter them anymore...
Could you set it to GADGET_MENUITEM again as before.
Thanks

#7

Hi Seb,
the GadgetClass of Menu gadgets are always set zero, so i can't filter them anymore...
Could you set it to GADGET_MENUITEM again as before.
Thanks

Done! I've added that to the next release of MaxGUI.Win32MaxGUIEx which also includes some memory leak/event fixes.

It should be available within a week if all goes to plan. I don't suppose it would be too hard to code in an official function to do the job (perhaps, a GadgetClass()?) - I'll have a look into this for you if I get time so you can have a cross-platform solution... ;-) If you need the fixes sooner, e-mail me and I'll see what I can do...

#8

Thanks a lot, mail is on the way.

#9

Thanks a lot, mail is on the way.

OK, I've just sent them to logicgui@logiczone..... I should probably reiterate that in their current state they have had very little testing so tread carefullly... ;-)

The SetPanelPixmap memleak i reported is fixed in the latest version you send me!
Thanks

The SetPanelPixmap memleak i reported is fixed in the latest version you send me!

Brilliant!

A new worklog entry (see the top two posts in this thread) has been posted for the rest of you outlining recently committed fixes for the pixmap memory leak in MaxGUI.Win32MaxGUIEx, and for the new GadgetClass() command.

Thank you very much, SebHoll.

The MaxGUI.Win32MaxGUIEx fix for HTMLView positioning has just been committed to SVN - the other fixes should follow within the week.

Thanks!

On German Keyboards "Ctrl" is called "Strg"
Is there a way to make the module compile differently under a German OS?

Line 3800:
"If modifier&2 m$="Strg+"+m$"

P.S.:
MaxGUI.Win32MaxGUIEx (v0.50) := MaxGUI.Win32MaxGUIEx (v0.51)! ;)

Is there a way to make the module compile differently under a German OS?

No, not at compile time, and any decisions at runtime would have to be a hack. Maybe at some point, someone will get round to making a BlitzMax language dictionary, but until then it looks like you may have to make the tweaks yourself. :-(

P.S.:
MaxGUI.Win32MaxGUIEx (v0.50) := MaxGUI.Win32MaxGUIEx (v0.51)! ;)

What do you mean???

I meant that you have to update the mod version at post #1 as well. ;)

I meant that you have to update the mod version at post #1 as well. ;)

Ooops, forgot about that! Thanks!

I'm proud to see an update which involve a part of my code ...

http://www.blitzbasic.com/Community/posts.php?topic=74279
quit a litle thing, but like this, I won't have to modify the maxgui source each time there 'll have an update !

I'm proud to see an update which involve a part of my code ...

Brilliant! This and a few other goodies should appear on SVN sometime in the next week if I don't fall behind schedule...

Hmm, updated to SVN rev.39 and the HTMLView doesn't work anymore. It got stuck in ClassWndProc when i try to create one.

Tested a bit the new gadget sensitivity and found following things:
It does not work with ComboBoxes at all.
With tabber it only acts on the tab itself and only the mouse not on the client area.
For windows only the inner client area is sensitive, so no statusbar or titlebar.
For labels only the mouse is sensitive, no keys.
When activating the sensitivity for buttons i get some strange results on checkboxes and radio buttons. A checkbox button can't be selected anymore and a radio button only if space is pressed but not via a left click.
Is this to be expected or what is a bug?

Hmm, updated to SVN rev.39 and the HTMLView doesn't work anymore. It got stuck in ClassWndProc when i try to create one.

You'll have to be more specific - debug/release mode, which line, what call stack?

For labels only the mouse is sensitive, no keys.

Key presses are always directed at the gadget currently in focus, and as labels cannot receive focus, they will not receive any keyboard events.

It does not work with ComboBoxes at all.

For windows only the inner client area is sensitive, so no statusbar or titlebar.

A window's titlebar isn't part of the gadget as far as MaxGUI is concerned - it's mouse events are handled by the Windows Manager, and so that's why they aren't passed onto MaxGUI.

When activating the sensitivity for buttons i get some strange results on checkboxes and radio buttons. A checkbox button can't be selected anymore and a radio button only if space is pressed but not via a left click.

I'll have a look into this for you...

For the labels and window i assumed so, but the combobox should have sensitivity, no?

Tried the HTMLView again and yes it happens only in debug mode! Release mode is working.

SuperStrict
Import MaxGui.Drivers

Local Logic_Gui:TGadget = CreateWindow:TGadget("Logic_Gui",232,83,731,372,Null,WINDOW_TITLEBAR|WINDOW_RESIZABLE |WINDOW_MENU |WINDOW_STATUS |WINDOW_CLIENTCOORDS )
	Local HTMLView1:TGadget = CreateHTMLView:TGadget(15,16,490,296,Logic_Gui:TGadget,Null)
		HtmlViewGo( HTMLView1:TGadget,"www.LogicZone.de")

Repeat
	WaitEvent()
	Select EventID()
		Case EVENT_WINDOWCLOSE
			Select EventSource()
				Case Logic_Gui	Logic_Gui_WC( Logic_Gui:TGadget )
			End Select

		Case EVENT_GADGETDONE
			Select EventSource()
				Case HTMLView1	HTMLView1_GD( HTMLView1:TGadget )
			End Select

	End Select
Forever

Function Logic_Gui_WC( Window:TGadget )
	DebugLog "Window Logic_Gui wants to be closed"
'	HideGadget( Window:TGadget )

	End
End Function

Function HTMLView1_GD( HTMLView:TGadget )
	DebugLog "HTML View HTMLView1 has finished loading the page"
	DebugLog "URL= " + HtmlViewCurrentURL$( HTMLView:TGadget )
	
End Function

It stops directly on the create ...

Thanks for having a look at this.

Regarding the HTMLView, whoops must have left a DebugStop in while fixing that HTMLView positioning bug - just comment line 278 out of maxgui.mod/win32maxguiex.mod/win32maxguiex.bmx for now, until the next release is committed (making sure to build modules afterwards).

Regarding the buttons, I've managed to hack a fix together for this, although for some reason Windows doesn't emit mouse-events on the ComboBoxes and so it's unlikely I'll be able to fix this.

I should maybe write a bit in the docs about SetGadgetSensitivity() being an experimental function, though, as due to its very nature, the events fired are likely to be vastly different depending upon the platform.

Yep, found the DebugStop and tested now also the HTMLView with the SetGadgetSensitivity, but there is no. Actually i don't think i would need all those events, but i could imagine some drag and drop or other features where it could be quite useful, but then we would need at least a mouse enter and leave event (may mouse move as well).

If all this is not really cross platform then we have to check case by case, but ok better than nothing. Any extra documentation which could help us would be perfect.
Thanks

although for some reason Windows doesn't emit mouse-events on the ComboBoxes and so it's unlikely I'll be able to fix this.

I've managed to find a workaround for this, so now ComboBoxes behave as they should when SetGadgetSensitivity() is called on them in Windows.

Fixes are now up on SVN and a new worklog has been posted.

Cheers Mark!

FYI, anyone who used to Import an object file with icons, etc in it and found it stopped working with maxguiEX, there's a simple fix.

Make sure your Import "some_resources.o" is before you Import maxgui.drivers.

Also make sure that your *.o file contains the xpmanifest if you want to retain the XP style look.

Thanks for adding GadgetClass().

Hey, WINDOW_CENTER is now official! Nice to see that happen.

Thanks for adding GadgetClass().

Hey, WINDOW_CENTER is now official! Nice to see that happen.

Just in case you didn't know, I do keep a worklog with all the recent changes or addition here:

MaxGUI Updates Worklog

There could well be some other useful addition that you haven't noticed yet in there, too. ;-)

I recommend using 0,0 for the topmost window position and then using WINDOW_CENTER on child windows.

New set of updates now available via SVN.

MaxGUI Updates Worklog

I have just found a bug with maxguiex. I have tried to patch multithreading compileroptions into maxide CE 2
and after compiling the IDE just shut down as soon as try to open a second source. After some trouble (try debugging with just one sourcefile open at time)
I have found the issue: (hopefully)

win32maxgui.bmx

Type TWindowsTreeNode Extends TGadget
...
Method Free()
		'Avoid firing events when freeing a treenode that is selected.
		If SendMessageW(_tree,TVM_GETNEXTITEM,TVGN_CARET,0) Then DeSelect()
		'Free treenode
		If _item Then SendMessageW(_tree,TVM_DELETEITEM,0,_item);_item=0
		'Redraw parent if we were its last child node
		If _parent Then 'not checked in current SVN Version
			If Not SendMessageW(_tree, TVM_GETNEXTITEM, TVGN_CHILD, _parent._item) Then _parent.RedrawNode()
		End If
		'Cleanup variables that could be circular references
		_parent = Null;_tree = 0;_SetParent Null
		'Release any handle we created using HandleFromObject() in Spawn()
		If _handle Then Release _handle
	EndMethod
...
End Type

This at least fixed the bug for me. So I think the control for _parent was just overseen.

Hi,

From what I remember, the only case where a TWindowsTreeNode's _parent would be Null is if you were freeing the node twice, which isn't encouraging as it means that MaxIDE CE must still be keeping a pointer to the node once it has been freed.

I haven't noticed this problem with the official MaxIDE, but it should probably fail silently instead (just in case).

As such, it would probably be better if we just test whether _parent is Null as this will, in itself, determine whether the node has been freed previously.

Therefore can I suggest the following instead:

	Method Free()
		If Not _parent Then Return
		'Avoid firing events when freeing a treenode that is selected.
		If SendMessageW(_tree,TVM_GETNEXTITEM,TVGN_CARET,0) Then DeSelect()
		'Free treenode
		If _item Then SendMessageW(_tree,TVM_DELETEITEM,0,_item);_item=0
		'Redraw parent if we were its last child node
		If Not SendMessageW(_tree, TVM_GETNEXTITEM, TVGN_CHILD, _parent._item) Then _parent.RedrawNode()
		'Cleanup variables that could be circular references
		_parent = Null;_tree = 0;_SetParent Null
		'Release any handle we created using HandleFromObject() in Spawn()
		If _handle Then Release _handle
	EndMethod

klepto: Can you please confirm that this works in the case of MaxIDE CE before I commmit it?

yes, works as well :)

Thanks! Committed!

From what I remember, the only case where a TWindowsTreeNode's _parent would be Null is if you were freeing the node twice, which isn't encouraging as it means that MaxIDE CE must still be keeping a pointer to the node once it has been freed.

Entirely possible. I know that code is screwy enough to generate null pointers all over the place due to the GTK errors, but haven't found the cause...

I can't compare a string with the treeview node name. The return string of the node name is a 256 buffer string, thus the compare never really works as expected.
Could this be corrected.
Thanks

Testcode

SuperStrict
Import MaxGui.Drivers

Local Window1:TGadget = CreateWindow:TGadget("Window1",357,138,236,143,Null,WINDOW_TITLEBAR|WINDOW_RESIZABLE |WINDOW_STATUS |WINDOW_CLIENTCOORDS )
	Local TreeView1:TGadget = CreateTreeView:TGadget(12,11,102,125,Window1:TGadget,Null)
		Local Node1:TGadget = AddTreeViewNode( "First",TreeViewRoot(TreeView1:TGadget) )
		Local Node2:TGadget = AddTreeViewNode( "Second",TreeViewRoot(TreeView1:TGadget) )

Print Node1.GetText()
Print Node2.GetText()

If Node1.GetText() = "First" Then Print "Nr.1" Else Print "No match"
If Node2.GetText() = "Second" Then Print "Nr.2" Else Print "No match"

Print "Node1 Name length="+Node1.GetText().length

Fix committed (rev. 97) - thanks!

Works fine :)

.

Not quite related with enhancements or requests...but read before delete me :D

I was posting an 'error' (on the MaxGUI thread) when I remembered that I was using STANDARD MaxGUI, while the old application I wrote 1 month ago was written with SVN MaxGUI. (To be specific is the LABEL_SEPARATOR problem...corrected in the SVN'MaxGUI - I spent an hour to check if I've done something stupid with the mod/installation/patches and so on...).

I think it's time to make 'standard' all (or some of) the improvements done until now! (So the next move 'beta to standard' can be done in June 09 or whatelse - just an idea! - so to have time to check if anything is ok)

Thanks!

I remembered that I was using STANDARD MaxGUI

I assume that you mean the MaxGUI downloadable through the 'Product Updates' page?

I think it's time to make 'standard' all (or some of) the improvements done until now!

So the next move 'beta to standard' can be done in June 09 or whatelse

I'm not entirely sure I understand... Are you saying that you would like a new standard release of MaxGUI to be uploaded to the 'Products Update' page now? Or do you want it in June 2009? I was planning on releasing a new MaxGUI package simply whenever there is a new BlitzMax release as there is some re-organisation of BRL.Event that have to be coordinated with the latest MaxGUI.

I assume that you mean the MaxGUI downloadable through the 'Product Updates' page?

yes - the 'standard' way to get it.

MaxGUI to be uploaded to the 'Products Update' page now? Or do you want it in June 2009? I was planning on releasing a new MaxGUI package simply whenever there is a new BlitzMax release as there is some re-organisation of BRL.Event that have to be coordinated with the latest MaxGUI.

I would like to see the 'current' version available via the Products Update page.
The WIP - non stable features of MaxGUI should be available only via SVN.

I was planning on releasing a new MaxGUI package simply whenever there is a new BlitzMax release as there is some re-organisation of BRL.Event that have to be coordinated with the latest MaxGUI.

Of course if the new MaxGUI implies 'new' features into the BRL standard (pub and brl) modules I/we need to wait until BRL will decide for this solution.

Does MaxGUI allow custom images?

It depends what you mean...

Yes, MaxGUI will allow you to have pixmaps on buttons on all platforms, and icons on menus on OS X and Windows. In addition, you can set a panel's background to a pixmap and have it tiled/centered/stretched to fit etc.

Looking at your "GUI Library" thread, I should probably point out that MaxGUI is not a 2D GUI rendering library. It is an interface to standard platform operating system controls to create windows and basic applications.

You may want to look at that one:
http://jsp.logiczone.de/downloads/SmartButtonDemo1.2.zip

It uses pure MaxGui and images/sound as an example.

I've just updated the splitter inside MaxGUI.ProxyGadgets, which should fix a few bugs and should also allow you more control on how the splitter behaves to user-interaction. See SetSplitterBehavior() after checking out the latest commit, and rebuilding mods/docs for more information.

The new splitter works perfect. I like it a lot more than the first version. Very well done! Thanks.

It's nice to know that people are using it... Thanks for the feedback jsp!

May I ask for a (hopefully) small request:
It would sometimes be nice to set the cursor shape to something 'own'.
The SetPointer command covers the most common things but not all, thus I would find it useful to have something like a SetPointerPixmap() command.
Hope that make sense.

The SetPointer command covers the most common things but not all, thus I would find it useful to have something like a SetPointerPixmap() command.

Something like this, perhaps?

Creating Custom Mouse Pointers (ChangeCursor mod)
Edit: Eeek! Looks like I lost it when my ISP decided to close down my free web-space WITHOUT TELLING ME!!!). If you want to take a look at it, I've found it on an old back-up disk for you so I can e-mail it over, but I've no idea whether it works with the latest MaxGUI.

I will have a look into this if I get a chance, but I've too much work atm. If I remember correctly it needed a standardized interface, and Win32MaxGUIEx/FLTKMaxGUI equivalents.

I can test it with the latest version, no problem. Anyhow it's not that urgent.

To have some cleaner code it would be nice to have a GetProxy:TGadget() method underneath the TProxyGadget.

To have some cleaner code it would be nice to have a GetProxy:TGadget() method underneath the TProxyGadget.

Done! Turn-around time: 15 minutes! ;-) See revision 125.

Perfect. Thanks Seb!