MaxGUI v1.33 RC1 is here!
BlitzMax Forums/MaxGUI Module/MaxGUI v1.33 RC1 is here!
| ||
MaxGUI v1.33 Release Candidate 1 is now available to MaxGUI users for download here: 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. |
| ||
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 |
| ||
THANK YOU! Any chance to see the ScrollPanel going cross-platfrom some day? |
| ||
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. ;-) |
| ||
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. |
| ||
Ok, I will check it this week end. Thanks again for the massive update! Cheers |
| ||
Great, thanks for the update, much appreciated as always :) Jason. |
| ||
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? :) |
| ||
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. |
| ||
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! |
| ||
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. |
| ||
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) |
| ||
@ 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? |
| ||
GetActiveWindow() That's a big assumption. |
| ||
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) |
| ||
@ 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 "+pathIf 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. |
| ||
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... |
| ||
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. |
| ||
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! |
| ||
degac: Just a note to say that these requester issues should be fixed in the next release of BlitzMax (whenever that is). |
| ||
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 €static Fl_Font Fl::set_fonts(const char*)€: /root/BlitzMax/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/fl_set_fonts_xft.cxx:274: error: invalid conversion from €const char*€ to €char*€ /root/BlitzMax/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/fl_set_fonts_xft.cxx:275: error: invalid conversion from €const char*€ to €char*€ /root/BlitzMax/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/fl_set_fonts_xft.cxx:280: error: invalid conversion from €const char*€ to €char*€ Build Error: failed to compile /root/BlitzMax/BlitzMax/mod/maxgui.mod/fltkmaxgui.mod/src/fl_set_fonts.cxx Process complete |
| ||
That's strange... Which version of gcc are you compiling with, and what distro are you using? |
| ||
arch linux gcc 4.4.0-5.1 |
| ||
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. |
| ||
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. |
| ||
@ Mr Paxman: This has been fixed for next release. ;-) |
| ||
thanks! |
| ||
@ 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. ;-) |
| ||
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... |
| ||
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. |