Wow
BlitzMax Forums/MaxGUI Module/Wow
| ||
Hey. Just wanted to say that I like the new listbox style!Strict Import maxgui.drivers Global window:TGadget=CreateWindow(AppTitle,50,50,640,480,Desktop(),1+2) Global listbox:TGadget=CreateListBox(5,5,ClientWidth(window)-10,ClientHeight(window)-10,window,LISTBOX_MULTISELECT) For Local i:Int=1 To 10 AddGadgetItem(listbox,"Item "+i) Next Repeat WaitEvent() Select EventID() Case event_windowclose Select EventSource() Case window End EndSelect Case event_gadgetaction Select EventSource() Case listbox Print "ACTION!" Local items[]=SelectedGadgetItems(listbox) For Local i:Int=EachIn items Print GadgetItemText(listbox,i) Next EndSelect EndSelect Forever And that I like the new splitter gadget in MaxGUI.ProxyGadgets! |
| ||
| I like the new splitter gadget in MaxGUI.ProxyGadgets! Cheers. ;-) Just wanted to say that I like the new listbox style! The reason why I haven't announced it publically yet is that I haven't got round to adding a Mac OS X (Cocoa) implementation. Also, I'm still not 100% sure I like how the API works atm. At present, calling SelectedGadgetItem() on a multi-select list box will return an item index if one and only one item is selected. If more than 1 is selected (or none at all), -1 is returned. Perhaps, this should return -2 if more than one item is selected instead of -1. Perhaps, SelectedGadgetItem() should return -2 no matter what is selected, forcing you to use SelectedGadgetItems(). Hmmmm.... The index specified in EVENT_GADGETSELECT's event.data field gives the first item index whose selection state has changed as a result of the user action. This item may or may not be selected, depending upon its original state. My original thinking was that knowing this is slightly more helpful than it simply passing -1 or the first selected item, albeit I don't think I like the incosistency with the standard listbox event data. In short, SelectedGadgetItems should be what is used to handle mutliselect listboxes, but we still need to decide what the single item commands/events return. As always, any thoughts or comments are greatly appreciated... |
| ||
| The reason why I haven't announced it publically yet is that I haven't got round to adding a Mac OS X (Cocoa) implementation. Oops. Guess I got a little excited. :P |
| ||
| Please make it easy to turn this feature off and please don't break existing apps by changing the basic commands, i.e changing the default behaviour. This feature shouldn't be enabled by default. LISTBOX_MULTISELECT - What's the flag to disable it? |
| ||
| LISTBOX_MULTISELECT - What's the flag to disable it? Er...excluding it from the flags you specify??? |
| ||
| SebHoll & co, can you make a post where - report (in a table maybe) what are now the gadget supported by MaxGUI and where (if any) are differences/bugs/malfunction in the different OS platform. - report what are the gadgets you are working on (so to know that they are 'experimental') - report what gadgets are missing (I have at least 2 hints...) - report what can not be done. It seems stupid, but I just noticed that there's nothing that resume what are the gadgets currently supported by MaxGUI. |
| ||
| SebHoll & co, can you make a post where - report (in a table maybe) what are now the gadget supported by MaxGUI and where (if any) are differences/bugs/malfunction in the different OS platform. - report what are the gadgets you are working on (so to know that they are 'experimental') At the moment, if it isn't in the MaxGUI docs, then it isn't supported. The only two places you need to look for a list of all the gadgets are MaxGUI.MaxGUI and MaxGUI.ProxyGadgets help pages. The experimental LISTBOX_MULTISELECT constant isn't mentioned at all in the docs - hence, it's not supported (yet). I think this is pretty fair way of doing it. If you wanna following the changelogs in the source code and use the cutting edge latest features before it is announced, then you're more than welcome to. Heck, any feedback while it's still a WIP is extremely useful so if you want to, please do. :-) If you don't want to use any of the experimental features, stick to MaxGUI à la docs. Rest assured any additions/improvements made to MaxGUI will not (intentionally) break any old code. If it has, let me know, and I'll try to fix it. Please make it easy to turn this feature off and please don't break existing apps by changing the basic commands, i.e changing the default behaviour. This feature shouldn't be enabled by default. LISTBOX_MULTISELECT - What's the flag to disable it? LISTBOX_MULTISELECT is a style flag that you can optionally specify in your call to CreateListBox(), just like you can otionally specify COMBOBOX_EDITABLE in the call to CreateComboBox(). If you don't use this flag when creating the gadget, the listbox and MaxGUI commands will behave exactly the same as before. The LISTBOX_MULTISELECT framework has been in for over a month, but nobody has reported any problems with listboxes as the behaviour for standard listboxes has remained the same. Rest assured, this should not break any existing code. Now that we've cleared that up, is everybody happy with the current arrangement I described above? - report what gadgets are missing (I have at least 2 hints...) - report what can not be done. I think that sort of stuff belongs in one of the many MaxGUI request threads. |
| ||
| is everybody happy with the current arrangement I described above? I am! nice job, cheers. |
| ||
| okidoki |
   |