Anyone had trouble running older builds on 10.9?
Archives Forums/MacOS X Discussion/Anyone had trouble running older builds on 10.9?
| ||
| A customer bought Holiday Bonus GOLD from the Mac App store and they have a Mac Book Pro with Mavericks. But they said it crashes (don't have more details yet). I compiled it last December 2012 on my Macbook Air which I guess was probably OSX 10.8 at the time. |
| ||
| I've not come across any problems. The only thing I can think of would be file permissions, where your game may be assuming it has access to something when it doesn't - and then falls over. But otherwise, old programs should work much in the same way as they used to. |
| ||
| I had an issues where I was writing to the app folder itself (setup details). Newer versions of osx crash if this happens, so that may be the cause? |
| ||
| I had an issues where I was writing to the app folder itself That's why we have the Library folder :-) And if you use Sandboxing (properly), all your stuff will go into app-specific folders inside your local Library when you use the system-provided paths for any locations you request via the APIs. |
| ||
| My users have big problems in using MaxGui. In all apps compiled on a 10.5 Mac, the drop down list gadget seems to open, but closes immediately, so the user are not able to select an item. Now bought a new 10.9 mac and I will see what happens.... In general we need a professional solution for a GUI for the future. MaxGui seems to get more and more problems. Could Bruceys WxGadget be the future? Does anybody has experiences with it? |
| ||
| Could Bruceys WxGadget be the future? Does anybody has experiences with it? [b]Pete Rigz uses it for his particle effects GUI. He doesn't appear to have too many problems with it - when he does, he gets vocal about it, so when I don't hear from him I assume all is well ;-) I use it for a lot of stuff too - my main platform is OS X. I'm currently on Mavericks too. Interestingly the IDE works fine here on Mavericks, including the comboboxes on the options dialog. |
| ||
| Hi Brucey, is the IDE compiled from a BlitzMax source code? In the IDE the list boxes work perfect. So perhaps I'm doing something wrong? At the moment I'm doing a lot of test with the MODs I usually use. It looks like "Koriolis Zipstream" has problems... This would be the worst case for me... All app are based on this module! Who can help? Koriolis Homepage seems to be offline now. ***EDIT*** koriolis seems to work now. I changed something in the "koriolis.mod/zipstream.mod/bmxsupport.c" // Small support functions for BlitzMax
// Author: Thomas Mayer
// License: Public domain code
#include "unzip.h"
#include "zip.h"
int unzGetCurrentFileSize (unzFile* zipFile)
{
unz_file_info fileinfo;
if (!zipFile)
//change this old line:
// return;
// to this new one:
return 0;
unzGetCurrentFileInfo ( zipFile, &fileinfo,
0,
0,
0,
0,
0,
0);
return fileinfo.uncompressed_size;
}
...
...
I started to "build modules" and during this process MaxGui now seems to have problems "mod/maxgui.mod/cocoamaxgui-mod/cocoa.macos.m" error message: MaxIDE Complie Error 6: error: conflicting types for NSClearItems" *** EDIT maxgui seems to work too inspite of the build problems... I could build my app now, but the list box problem is still there. I can simulate the problem: If you add a canvas to the code example of blitzgui "CreateComboBox" you can see the problems: ' createcombobox.bmx Strict Import MaxGui.Drivers AppTitle = "ComboBox Style Example" Global window:TGadget = CreateWindow( AppTitle, 100, 100, 300, 200, Null, WINDOW_TITLEBAR|WINDOW_STATUS ) '***** only two new lines: Global Canvas:TGadget =CreateCanvas(0 , 0 , 2000, 1000 , Window) SetGadgetLayout Canvas , 1,0,1,0 '********** CreateLabel( "No Style (0): ", 5, 5, ClientWidth(window)-10, 24, window, LABEL_LEFT ) Global stdComboBox:TGadget = CreateComboBox( 5, 29, ClientWidth(window)-10, 26, window, 0 ) ... ... |
| ||
| Brucey, could I ask... What IDE are you using for BlitzMax for osx? |
| ||
| MaxIDE 1.42 (according to the "About MaxIDE" dialog) I use it for all my coding, and build/run of apps. I build modules from the Terminal. As a basic editor it does fine, and it's project/file tree is, of course, BlitzMax oriented. The treeview does need a kick now and again though because it's not really designed to cope well with the sheer amount of nodes I have here (in the modules source). But if you look at the source for the treeview stuff in the IDE, it's trying to be a model/view type thing, and maybe it needs some reviewing - at least in so-far as how it builds the treeview. Otherwise, it's fine for what I use it for. |
| ||
| hi Brucey, did you see the modified CreateComboBox() code sample I added afterwards to my last post? It demonstrates the bug! |
| ||
| Ah, so you have a combobox on top of a GL context? I imagine that there's something going on related to the way the context is working. One possible way to overcome this is to create a transparent window/widget/control) which covers your context, and then add all your controls to that instead of being direct siblings of the context view. Off the top of my head, I'm not sure how you make transparent controls in MaxGUI. You can do it in cocoa with setOpaque:NO So, at the moment you have this :
Window
-> Canvas
-> Combobox
Using a transparent window for the combo's parent you'd have :
Window
-> Canvas
-> Tansparent Panel
-> Combobox
Not to say it would work, of course. Just a bit of theory :-) |
| ||
| Is mixing a full-window canvas and native controls really a good idea though? If you are going to all the trouble of full-window GL, couldn't you simulate the rest of the controls in Max2D or some such? |
| ||
| Talking of Mavericks, Mister MidiMaster :-) I downloaded your Minis demo pack, and tried DrumChampion. You have a flicker problem when the demo-popup pops up. To an untrained eye, it looks like it is flicking between an old frame of the main loop, and a black frame with your popup on it. Now, when I clicked on Weiter the first time I ran it, it crashed. The second time, it got to the spinning DEMO text thing, and then when I quit the app, it crashed. Both times it crashes on a call to brl_stream_WriteLine. I hope you aren't trying to write anything to the App bundle. DrehZirkel didn't crash on quit, but the Help dialog flickers in the same way as above. KlangPaare crashed when I tried to open the drawer. Perhaps an issue with ReadDir. Other demos have the same Demo popup flicker problems. |
| ||
| Thank you Brucey for your tests and pointing me to possible reasons. That's what users reported me too. And that is the reason I bought a new MAC. On 10.5 to 10.7 everything still worked fine. Now I have to do a lot editing. I start with my top seller app "rhythm trainer", the MINIs following later... I never heard before, that a canvas should not combined with other GUI elements. I thought, that the Canvas is only one of the gui elements and the OS will care about the right moment to draw the content. Now in new Maverick it looks like the canvas is always drawn last. Is this really no bug? I need the chance of opening a "option window" on top of the game, while the game remains still visible in the background. Free canvas position and z-order worked perfect until now. And it still works perfect together with all other GUI elements. Only the ComboBox() produce errors. Really no bug? What happens, if you combine a full window canvas and a ComboBox() in a WxMax based GUI? Can you please try to simulate this on your WxMax? I will do some further experiments on MaxGui now... In my source code I found old code lines, which I commented out in former times: ' SetGadgetShape Canvas, 0 , 0 , WindowBreite , WindowHoehe*2/3 So it looks like, I thought about the need of "bordering the canvas", but decided, that it seems not to be necessary... Keep on struggling.... |
| ||
| Thanks for the feedback. I got a number of people to test it and it seemed fine, so it's just that one customer (that I know of). It probably is some kind of failed permissions thing then even though I'm saving to the correct folder. I may have to make that code more stable by trying to save in other locations if that one fails or failing that, not saving at all! |
| ||
| news on Canvas problem: Now it looks like the typical EVENT_TIMERTICK practice is responsible for the problems: In my window I created a new panel 200x200pix. Inside there is a 300x300 canvas. below the panel there are the combo boxes at 100,400 far away from the problematic area. When I now add a timer and use the EVENT_TIMERTICK to fresh up the game screen, the combo boxes do not longer work as expected. With a timer rate below 60 the problem seems not to there, but it only look like: the problem appear seldom. With a timer rate of 120 the problem appears always: I would have expected, the OS cares about correct viewports inside GUI elements. |
| ||
| My stuff runs fine under 10.9.1 but i know from others that's not generally the case. It depends on what you're doing in detail and your exact machine/configuration. Maverick compared to its predecessors is a big improvement in a number of fields but it still doesn't feel as solid as Snow Leopard once was. |
| ||
| Maybe I found a solution.... The MaxGui manual shows a complete new way to handle events. I do not understand what happens, but it looks a little bit like "Monkey". I'm talking about the RedrawGadget() command help sample. It looks like Mark changed fundamental the way the Events should be used by BlitzMax: Type TApplet
Method OnEvent(Event:TEvent) Abstract
Method Run()
AddHook EmitEventHook,eventhook,Self
End Method
Function eventhook:Object(id,data:Object,context:Object)
Local event:TEvent = TEvent(data)
Local app:TApplet = TApplet(context)
app.OnEvent( event )
Return data
End Function
End Type
Type TSpinningApplet Extends TApplet
.....
Method OnEvent(event:TEvent)
If Not event Then Return
Select event.id
Case EVENT_WINDOWCLOSE, EVENT_APPTERMINATE
End
Case EVENT_TIMERTICK
RedrawGadget( canvas )
Case EVENT_GADGETPAINT
If (event.source = canvas) Then Draw()
End Select
End Method
Method Create:TSpinningApplet(name$)
window = CreateWindow( name, 20, 20, 512, 512 )
....
Run()
Return Self
End Method
End
Local spinner:TSpinningApplet = New TSpinningApplet.Create("Spinning Applet")
Repeat
WaitSystem()
Forever
If I here add my too big canvas enclosed in a panel the ComboBox does not flicker anymore.... Method Create:TSpinningApplet(name$) If Not image Then image = LoadImage( "fltkwindow.png" ) window = CreateWindow( name, 20, 20, 512, 512 ) 'Local w = ClientWidth(window) 'Local h = ClientHeight(window) ' ***** ADDITIONAL TEST CODE FOR COMBOBOX TEST Local panel:TGadget = CreatePanel(0,0,200,200,window,PANEL_ACTIVE) SetGadgetLayout panel, EDGE_ALIGNED, EDGE_ALIGNED, EDGE_ALIGNED, EDGE_ALIGNED SetGadgetColor panel ,0,255,0 Canvas:TGadget =CreateCanvas(5 , 5 , 400, 400 , panel) 'canvas = CreateCanvas( 0, 0, 700, 300, window ) 'SetGadgetLayout( canvas, EDGE_ALIGNED, EDGE_ALIGNED, EDGE_ALIGNED, EDGE_ALIGNED ) Global editcombobox:TGadget = CreateComboBox( 5, 203, ClientWidth(window)-10, 26, window, COMBOBOX_EDITABLE ) AddGadgetItem editcombobox, "United Kingdom" AddGadgetItem editcombobox, "United States", True timer = CreateTimer( 120 ) ' ****** END OF CHANGES Run() Return Self End Method Can somebody teach me, what happens, and what is the difference? I would like to integrate this into my rhythm trainer... |
| ||
| The MaxGui manual shows a complete new way to handle events It's been a looong time since I did any "real" work with MaxGUI, but what you say is a new way, looks kind of normal to me. It's basically running off event generation, rather than a hard-loop - which is how most GUI systems tend to work - wxWidgets, Qt, etc. Why is this better? Mainly because the system tells your program when things happen, and when you should update, rather than you forcing updates to occur on a control when perhaps the system isn't ready (or sync'd) to do so. In wxMax, you connect your buttons and updates to callback functions, which are called when a particular event is raised. There is no main loop for you to control - you simply create a subclass of wxApp, and call it's Run() method. |
   |