MaxGUI v1.33 RC1 is here!

BlitzMax Forums/MaxGUI Module/MaxGUI v1.33 RC1 is here!

SebHoll(Posted 2009) [#1]
MaxGUI v1.33 Release Candidate 1 is now available to MaxGUI users for download here:

MaxGUI v1.33 RC1 (Superseded by MaxGUI v1.34)



Back up your old BlitzMax/mod/maxgui.mod folder, and extract the above zip file into BlitzMax/mod. Although not required on Windows, Mac OS X (Intel) or Linux, it is recommended that you run Program->Build Modules from MaxIDE yourselves, after extracting MaxGUI. (Windows users would, however, require MinGW to be correctly installed and set-up.) Finally, all users should run Program->Rebuild Documentation to finish the update.

Apart from the new cross-platform Scroll Panel gadget (yes people - MaxGUI finally has a scroll panel! :D), this is predominantly a bug-fix release as there were a tonne of fixes building up at my end. Below are the ones I noted, but I'm sure there were quite a few other small fixes I have forgotten about.

MaxGUI.MaxGUI
> Added GetWidth() etc. methods to TGadget for TProxyGadget.
> Added recursive source.source handling to PostGuiEvent/QueueGuiEvent.
> Added some internal event queueing functions.
> Tweaked some docs.

MaxGUI.CocoaMaxGUI
> Fixed NSSetPointer through disableCursorRects calls.
> Fixed HTMLView navigation bugs, and added support for both style constants.
> Finished treeview icon support.
> Fixed listview/treeview scrollbar problems.
> Added recursive owner.source handling to EmitCocoaOSEvent.
> PanelViews now extend and use NSBox.
> Added separator for statusbar.
> Attempt to fix PANEL_SUNKENFRAME offset issues.
> LABEL_SUNKENFRAME alignment fix.
> Added TCocoaGuiFont and corresponding Delete() method.
> Attempt to fix button fonts and colors.
> Fixed ClearGadgetItems() for tabber.
> Fixed exception when freeing tabbers.

MaxGUI.FLTKMaxGUI
> Fixed stray EVENT_GADGETACTION event when enter was pressed in a textfield.
> Fixed push buttons losing background colors on mouse hover.
> Implemented new trial OnMouse() and OnKey() system for generating mouse and key events, that facilitates SetSensitivity().
> Added Flmm_Tabs so that, when too many tabs are added to a tabber, a drop-down menu is shown instead of squashing them up.
> Added degac's label text fix.
> LABEL_FRAME border fix.
> Added toolbar separators.
> Fixed comboboxes losing selection after ModifyGadgetItem.
> Fixed RemoveGadgetItem on toolbars.

MaxGUI.ProxyGadgets
> Added a new TScrollPanel gadget.
> Tweaked THyperlinkGadget.eventHandler() so that it works consistently on all platforms.

MaxGUI.Win32MaxGUIEx
> Fixed toolbar ListItemState() and loss of state on ModifyGadgetItem.
> Fixed recursive PopupWindowMenu event extra bug when using hooks.
> Standard checkboxes/radio-buttons now support text colors, but do so by losing theming.
> Fixed hotkey focus issues for window menus.
> Added recursive owner.source handling to SystemEmitOSEvent.


Please let me know how you guys get on, particularly if you experience any problems. There are a few bug reports outstanding in the MaxGUI Bug Reports forum, but I'm only one person and I didn't want to delay this batch of fixes while I scratch my head on the few remaining issues. We're also still waiting for the FLTK devs to reply to the bug reports posted with the toolkit.


degac(Posted 2009) [#2]
FLTK

When I click on a gadget 'sensitized', its content is cleared as expected.
But when I press a key to write something in it I get a SEGMENTATION FAULT error (in debug mode)

Import maxgui.drivers
Global window:tgadget
		window=CreateWindow("test",100,100,400,300,,WINDOW_TITLEBAR|WINDOW_CENTER)

Local txt_0:tgadget=CreateTextField(10,10,200,20,window
Local txt_1:tgadget=CreateTextField(10,40,200,20,window,TEXTFIELD_PASSWORD)
Local txt_2:tgadget=CreateLabel(" ",10,80,200,20,window,label_sunkenframe)
		
SetGadgetText txt_0,"Type here something!"
CreateLabel("This gadget has Sensitivity activacted!",220,10,200,40,window)

SetGadgetSensitivity txt_0,SENSITIZE_MOUSE
SetGadgetColor txt_1,240,20,20


While WaitEvent()
      Select EventID()
	Case event_mousedown
		If EventSource()=txt_0
			SetGadgetText txt_0,""
		End If
	End Select
Wend
End



Grisu(Posted 2009) [#3]
THANK YOU!

Any chance to see the ScrollPanel going cross-platfrom some day?


SebHoll(Posted 2009) [#4]
Any chance to see the ScrollPanel going cross-platfrom some day?


It's already cross platform, Grisu... You shouldn't expect anything less from a ProxyGadget. ;-)


SebHoll(Posted 2009) [#5]
degac:

Eeek - that's quite a gaping bug. That's not just with *sensitive* text-fields, it crashes when anything is entered into ANY type of text-field.

This has been fixed for release, but if you need a fix urgently, replace BlitzMax/mod/maxgui.mods/fltkmaxgui.mod/fltkgui.bmx's TFLTKGUIDriver.KeyFilter() function with:

	Function KeyFilter(obj:Int) "C" nodebug
		Local	source:TFLWidget
		Local	event:TEvent
		Local	key,mods,text$,i
		source=TFLWidget(HandleToObject(obj))
		
		If flEventKey()=FL_KEY_Control_R Return 0
		If source And (source.eventfilter<>Null) Then
			key=BlitzKeyFromFlConst(flEventKey())
			text$=fleventtext()
			mods=flstatetomodifiers(flEventState())
			If key
				event=CreateEvent(EVENT_KEYDOWN,source,key,mods)
				If Not source.eventfilter(event,source.context) Then Return 0
				'Unlike the other platforms, text isn't set by FLTK when combining tab with modifier keys
				If Not text And key = KEY_TAB Then text="~t"
			EndIf
			For i=0 Until text.length
				key=text[ i]
				event=CreateEvent(EVENT_KEYCHAR,source,key,mods)
				If Not source.eventfilter(event,source.context) Then Return 0
			Next
		EndIf
		Return 1
	End Function
...then the flReset() extern declaration in fltkdecl.bmx with...

Function flReset(xdisplay,callback:Int(event),filter:Int(user:Int),mousehandler:Int(flwidget,user:Int),keyhandler:Int(flwidget,user:Int))
...and finally fltkglue.cpp's Fl_AInput with:

class Fl_AInput:public Fl_Input
{
public:
	Fl_AInput(int x,int y,int w,int h,const char *title=0):Fl_Input(x,y,w,h,title)
	{}
	
	int handle(int event)
	{
		int res = 0;
		switch (event)
		{
		case FL_DRAG:
		case FL_PUSH:
		case FL_RELEASE:
			mousehandler(this, user_data());
			res = 1;
			break;
		case FL_KEYDOWN:
			if (textfilter(user_data())==0) return 1;
			do_callback();
			break;
		}
		
		return Fl_Input::handle(event)||res;
	}
};
...and build modules.


degac(Posted 2009) [#6]
Ok, I will check it this week end.
Thanks again for the massive update!

Cheers


QuickSilva(Posted 2009) [#7]
Great, thanks for the update, much appreciated as always :)

Jason.


Ked(Posted 2009) [#8]
Thanks for the update!

Quick question: Will the Windows module ever be compatible with older, non-unicode versions of Windows right out of the box? Maybe some simple "If _bbusew" code stuck here and there? :)


klepto2(Posted 2009) [#9]
Hi

RequestFile is not working correctly under windows.

Here is the fix:


	Function Request:TWindowsFont(font:TGuiFont)
		Local	lf:LOGFONTW
		Local	cf:CHOOSEFONT
		Local	hwnd,n,i,hfont

		lf=New LOGFONTW
		cf=New CHOOSEFONT		
		cf.lStructSize=SizeOf(cf)
		cf.hwndOwner=TWindowsGUIDriver.GetActiveHwnd()
		cf.lpLogFont=lf
		cf.Flags=CF_BOTH
		If font
			Local p:Short Ptr=Short Ptr(Varptr lf.lfFaceName00)
			n=font.name.length
			If n>31 n=0
			For i=0 Until n
				p[i]=font.name[i]
			Next
			SetLogFontProperties( lf, font.style, font.size )			
			cf.Flags:|CF_INITTOLOGFONTSTRUCT
		EndIf
		hwnd=GetFocus()
		n=ChooseFontW(cf)
		SetFocus(hwnd)
		If Not n Return
		Local style
		If cf.nFontType&BOLD_FONTTYPE style:|FONT_BOLD
		If cf.nFontType&ITALIC_FONTTYPE style:|FONT_ITALIC
		'SetLogFontProperties( lf, style, cf.iPointSize/Double(10) )
		Return New TWindowsFont.LoadFromLogFont( lf,cf.iPointSize/Double(10), style  )
	EndFunction
	


In the current Version you set the LogFontproperties twice, the first time you set the correct values, but the second time from LoadFromLogFont you use empty arguments and set the font back to style 0 and size 0.


SebHoll(Posted 2009) [#10]
RequestFile is not working correctly under windows.

Here is the fix:

Nice spot klepto2! This must have been broken for a while so I'm suprised it hasn't been reported before. Anyhoo, this will be corrected in the next release.

Thanks!


Ked(Posted 2009) [#11]
RequestFile is not working correctly under windows.

Note that that code is for RequestFont, not RequestFile.

However, we do have problems with RequestFile and RequestDir. They don't seem to have "parents." They aren't being dialog windows anymore.


degac(Posted 2009) [#12]
Another question about RequestDir under Win32

RequestDir$( text$,initial_path$="" )

the user should choose a folder from where the application is saved (ie: c:\program\my_app). RequestDir("Choose a folder","C:\program\my_app") should display a requester showing the current application dir. Indeed I have - ever - the list of complete resourse of computer

Desktop
+ Documents
+ Computer Resource
+ Network

and I need to manually open 'Computer Resources', 'C:', 'Program' and so on...

I don't remember if RequestDir worked differently before...
RequestFile works as expected (open the initial_path)


SebHoll(Posted 2009) [#13]
@ Ked:

However, we do have problems with RequestFile and RequestDir. They don't seem to have "parents." They aren't being dialog windows anymore.

RequestDir() and RequestFile() are standard BlitzMax functions defined in Brl.System and so this isn't actually a MaxGUI bug. For fear of going off-topic, I'll suggest a quick-fix.

I'm not sure why, but if you have a look at the bbSystemRequestDir() and bbSystemRequestFile() functions in BlitzMax/mod/brl.mod/system.mod/system.win32.c, the following line is commented out:

//	bi.hwndOwner=GetActiveWindow();
Try uncommenting them and building modules - I'm guessing this will reinstate the parenting behaviour, but I'm guessing there must be a *reason* why this was done, and I'm hesitant to suggest otherwise without knowing why.

I've flagged this query for you with the dev team, and hopefully we'll find out what's happening.

@degac:

I'm not sure I understand - are you saying you want to be able to specify "My Computer" or an equivalent special folder location as the default directory?


Brucey(Posted 2009) [#14]
GetActiveWindow()

That's a big assumption.


degac(Posted 2009) [#15]
Ok I post an image to clarify



As you can see I choose a specific folder (in this case D:\_blitzmax) but RequestDir 'starts' from 'My computer'

(To be honest I dont' know if this is the standard behaviour or not...and I dont' remember what is the behaviour on the other platforms)


SebHoll(Posted 2009) [#16]
@ Brucey:
That's a big assumption.

True - it's not nice, but that's the best decision we can make given the info passed to the function. And it's the same assumption that Notify(), Proceed() and Confirm() use. I agree, if I would have written the requester function, I probably would have done things differently, but anyhoo...

@ degac:

Does the following work as expected? It seems to work for me.

' requestdir.bmx

path$=RequestDir("Select a Folder","C:\") 'Should open with the root of the C drive selected.

Print "directory selected was "+path
If so, I'm guessing it's the use of the underscore '_' in the filename which is causing the problem. Either way, please post in the BlitzMax Bug Reports forum with your findings.


degac(Posted 2009) [#17]
Strange.
Tested on 1.30 and 1.30SVN (I still have these versions installed...) and RequestDir works as expected - it opens the path specified.

I will try to reinstall BlitzMax...


degac(Posted 2009) [#18]
Ok.
Reinstalled (in a separate folder) BlitzMax 1.33 rc 5 (no MaxGUI)
Re-builded modules.

Tested with the following sample
path$=RequestDir("Select a Folder","d:\") 'Should open with the root of the D drive selected.
Print "directory selected was "+path

Same result as my image posted above.


Ked(Posted 2009) [#19]
RequestDir() and RequestFile() are standard BlitzMax functions defined in Brl.System and so this isn't actually a MaxGUI bug.

Oh. Whoops. :)

Try uncommenting them and building modules - I'm guessing this will reinstate the parenting behaviour, but I'm guessing there must be a *reason* why this was done, and I'm hesitant to suggest otherwise without knowing why.

Wouldn't it be possible (and maybe easier) just to extend the current system driver and replace the RequestFile and RequestDir methods with MaxGUI friendly ones that make sure a MaxGUI window gets parented, not some other active one? I think the FLTK and GTK modules do this.

But since you found a solution for me just by uncommenting a line (which I'm not sure how I missed) this is good for now! :)

I've flagged this query for you with the dev team, and hopefully we'll find out what's happening.

Thanks for your help!


SebHoll(Posted 2009) [#20]
degac:
Just a note to say that these requester issues should be fixed in the next release of BlitzMax (whenever that is).


slenkar(Posted 2009) [#21]
In linux I get this
blitzmax134rc3
Compiling:fl_set_fonts.cxx
In file included from /root/BlitzMax/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/fl_set_fonts.cxx:39:
/root/BlitzMax/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/fl_set_fonts_xft.cxx: In static member function &#128;static Fl_Font Fl::set_fonts(const char*)&#128;:
/root/BlitzMax/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/fl_set_fonts_xft.cxx:274: error: invalid conversion from &#128;const char*&#128; to &#128;char*&#128;
/root/BlitzMax/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/fl_set_fonts_xft.cxx:275: error: invalid conversion from &#128;const char*&#128; to &#128;char*&#128;
/root/BlitzMax/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/fl_set_fonts_xft.cxx:280: error: invalid conversion from &#128;const char*&#128; to &#128;char*&#128;
Build Error: failed to compile /root/BlitzMax/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/fl_set_fonts.cxx
Process complete


SebHoll(Posted 2009) [#22]
That's strange... Which version of gcc are you compiling with, and what distro are you using?


slenkar(Posted 2009) [#23]
arch linux
gcc 4.4.0-5.1


Brucey(Posted 2009) [#24]
Later versions of gcc are ever more picky about correct syntax. hence char* != const char*.

You could straight cast, or const_cast<>. Or perhaps fix whatever underlying assumption is broken.


Grisu(Posted 2009) [#25]
Is it possible to "force" a scrollpanel not to display a scrollbar at all?

I'd love to make a smooth credits scroller with this and the scrollbar isn't needed for the user.


SebHoll(Posted 2009) [#26]
@ Mr Paxman:

This has been fixed for next release. ;-)


slenkar(Posted 2009) [#27]
thanks!


SebHoll(Posted 2009) [#28]
@ Grisu:
Is it possible to "force" a scrollpanel not to display a scrollbar at all?

SCROLLBAR_HNEVER and SCROLLPANEL_VNEVER have been added for the next release. ;-)


Grisu(Posted 2009) [#29]
Thanks!

Btw:
Can one use the scrollpanel on an already existing (smaller) panel?

I don't even get a scrollbar when doing so? :o)


ScrollPanelTop=0
ScrollPanelBottom=2147483647?

Might have broken it. I'm good at this...


SebHoll(Posted 2009) [#30]
I'm not entirely sure what you mean... You can parent a scrollpanel to a panel just like you can with any other gadget, but you can't specify your own panel to use for the client area/viewport - these are created and maintained by the scrollpanel gadget.