From ron at ...572... Tue Jan 4 15:24:18 2011 From: ron at ...572... (Ron) Date: Tue, 04 Jan 2011 15:24:18 +0100 Subject: [Gambas-devel] System error... (42) In-Reply-To: <201012311440.17016.gambas@...1...> References: <201012311440.17016.gambas@...1...> Message-ID: <4D232D92.2030805@...572...> On 31-12-2010 14:40, Beno?t Minisini wrote: >> Beno?t, >> >> trying to debug this problem, but if I follow your instructions, I get >> this right away.. are you sure they are correct? >> >> on at ...218...:~/domotiga/DomotiGaServer$ gdb gbx2 >> GNU gdb (GDB) 7.1-ubuntu >> Copyright (C) 2010 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to >> change and redistribute it. There is NO WARRANTY, to the extent permitted >> by law. Type "show copying" and "show warranty" for details. >> This GDB was configured as "i486-linux-gnu". >> For bug reporting instructions, please see: >> ... >> Reading symbols from /usr/local/bin/gbx2...done. >> (gdb) break THROW >> Breakpoint 1 at 0x804be2e: file gb_error.c, line 273. >> (gdb) run >> Starting program: /usr/local/bin/gbx2 >> [Thread debugging using libthread_db enabled] >> >> Breakpoint 1, THROW (code=13) at gb_error.c:273 >> 273 void THROW(int code, ...) >> (gdb) bt >> #0 THROW (code=13) at gb_error.c:273 >> #1 0x08057162 in get_stream (value=0x807fad0, can_default=> optimized out>) at gbx_subr_file.c:146 >> #2 0x0805717c in SUBR_close () at gbx_subr_file.c:187 >> #3 0x0806b0f3 in EXEC_loop () at gbx_exec_loop.c:476 >> #4 0x0804f533 in EXEC_function_loop () at gbx_exec.c:703 >> #5 0x0804f809 in EXEC_function_real () at gbx_exec.c:690 >> #6 0x08061c29 in main (argc=134739048, argv=0xbffff544) at gbx.c:349 >> >> I guess it stops at every error now, even known ones... >> >> Regards, >> Ron_2nd. >> > This is not your error (42). THROW is raised a lot of time, but you may not > see it because a TRY or a CATCH can intercept it, or because the interpreter > internally catches it. > > To catch only system errors. Add that to the THROW() function, in gb_error.c, > at line 278: > > if (code == 42) BREAKPOINT(); > > Compile and install again. > > Then run your program into gdb until it stops at that line. > > Once done, don't forget to remove that line, otherwise your program will stop > at that line even outside of the debugger. > > Regards, > > Ok this is funny. I ran my project for days in a row, to see if the system error #42 ever comes again. After an uptime of 5 days I finally got one. But it didn't ran inside a gdb session ;-( I added the breakpoint line to gb_error.c like you described above, started the project inside gdb and it occurred right away... lucky ;-) See attached gdb output. Hope you can find the bug with it, if not will get some more info. It has to do with a TCP socket _Ready event and getting some data, I think, but I have several sockets. This code was running: http://www.domotiga.nl/browser/tags/0.1.193/DomotiGaServer Regards, Ron_2nd. BTW: Is't a command line program running gb.qt on Ubuntu 10.04 32 bits and Gambas2 rev 3346 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gdb output.txt URL: From ron at ...572... Tue Jan 4 15:44:20 2011 From: ron at ...572... (Ron) Date: Tue, 04 Jan 2011 15:44:20 +0100 Subject: [Gambas-devel] System error... (42) In-Reply-To: <4D232D92.2030805@...572...> References: <201012311440.17016.gambas@...1...> <4D232D92.2030805@...572...> Message-ID: <4D233244.4030304@...572...> On 4-1-2011 15:24, Ron wrote: > On 31-12-2010 14:40, Beno?t Minisini wrote: >>> Beno?t, >>> >>> trying to debug this problem, but if I follow your instructions, I get >>> this right away.. are you sure they are correct? >>> >>> on at ...218...:~/domotiga/DomotiGaServer$ gdb gbx2 >>> GNU gdb (GDB) 7.1-ubuntu >>> Copyright (C) 2010 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later >>> This is free software: you are >>> free to >>> change and redistribute it. There is NO WARRANTY, to the extent >>> permitted >>> by law. Type "show copying" and "show warranty" for details. >>> This GDB was configured as "i486-linux-gnu". >>> For bug reporting instructions, please see: >>> ... >>> Reading symbols from /usr/local/bin/gbx2...done. >>> (gdb) break THROW >>> Breakpoint 1 at 0x804be2e: file gb_error.c, line 273. >>> (gdb) run >>> Starting program: /usr/local/bin/gbx2 >>> [Thread debugging using libthread_db enabled] >>> >>> Breakpoint 1, THROW (code=13) at gb_error.c:273 >>> 273 void THROW(int code, ...) >>> (gdb) bt >>> #0 THROW (code=13) at gb_error.c:273 >>> #1 0x08057162 in get_stream (value=0x807fad0, can_default=>> optimized out>) at gbx_subr_file.c:146 >>> #2 0x0805717c in SUBR_close () at gbx_subr_file.c:187 >>> #3 0x0806b0f3 in EXEC_loop () at gbx_exec_loop.c:476 >>> #4 0x0804f533 in EXEC_function_loop () at gbx_exec.c:703 >>> #5 0x0804f809 in EXEC_function_real () at gbx_exec.c:690 >>> #6 0x08061c29 in main (argc=134739048, argv=0xbffff544) at gbx.c:349 >>> >>> I guess it stops at every error now, even known ones... >>> >>> Regards, >>> Ron_2nd. >>> >> This is not your error (42). THROW is raised a lot of time, but you >> may not >> see it because a TRY or a CATCH can intercept it, or because the >> interpreter >> internally catches it. >> >> To catch only system errors. Add that to the THROW() function, in >> gb_error.c, >> at line 278: >> >> if (code == 42) BREAKPOINT(); >> >> Compile and install again. >> >> Then run your program into gdb until it stops at that line. >> >> Once done, don't forget to remove that line, otherwise your program >> will stop >> at that line even outside of the debugger. >> >> Regards, >> >> > > Ok this is funny. > > I ran my project for days in a row, to see if the system error #42 > ever comes again. After an uptime of 5 days I finally got one. > But it didn't ran inside a gdb session ;-( > > I added the breakpoint line to gb_error.c like you described above, > started the project inside gdb and it occurred right away... lucky ;-) > > See attached gdb output. > Hope you can find the bug with it, if not will get some more info. > It has to do with a TCP socket _Ready event and getting some data, I > think, but I have several sockets. > This code was running: > http://www.domotiga.nl/browser/tags/0.1.193/DomotiGaServer > > Regards, > Ron_2nd. > > BTW: Is't a command line program running gb.qt on Ubuntu 10.04 32 bits > and Gambas2 rev 3346 > Well it throws the error every time now, code=42 isn't that unknown it seems.. or there is something wrong with above line inserted at line 278? Removed it so it can run.. Regards, Ron. From kevinfishburne at ...590... Wed Jan 5 21:34:53 2011 From: kevinfishburne at ...590... (Kevin Fishburne) Date: Wed, 05 Jan 2011 15:34:53 -0500 Subject: [Gambas-devel] gb3: Image.Draw method is missing when using gb.sdl Message-ID: <4D24D5ED.50006@...590...> I'm in the process of converting my app from gb.image only to gb.image + gb.sdl to improve rendering performance. To my horror I noticed that the Draw method is no longer available. I'm using the following components: gb gb.image gb.image.effect gb.image.io gb.net gb.sdl gb.sdl.sound There is a Copy method, though it doesn't have parameters to specify the destination coordinates or width/height for scaling. It's like the Draw method with only the first four parameters. Interestingly good old DrawAlpha seems to still be there (yay!). Should there be a Draw method, or is there a different way to achieve the same functionality? It looks like using "Draw.Image(...)" will work, so I may have to integrate my rendering directly into the SDL backbuffer (Screen_Draw[]), though that would require a rewrite of the rendering pipeline. Final question, if there was an Image.Draw method, would that bypass SDL and use software rendering? If so it may be best for me to rewrite the rendering pipeline so it's pure SDL. -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: sales at ...590... phone: (770) 853-6271 From lordheavym at ...176... Fri Jan 7 23:16:30 2011 From: lordheavym at ...176... (Laurent Carlier) Date: Fri, 07 Jan 2011 23:16:30 +0100 Subject: [Gambas-devel] gb3: Image.Draw method is missing when using gb.sdl In-Reply-To: <4D24D5ED.50006@...590...> References: <4D24D5ED.50006@...590...> Message-ID: <4d2790c3.8a1ce30a.21af.ffff9fd1@...666...> Le mercredi 5 janvier 2011 15:34:53, Kevin Fishburne a ?crit : > I'm in the process of converting my app from gb.image only to gb.image + > gb.sdl to improve rendering performance. To my horror I noticed that the > Draw method is no longer available. I'm using the following components: > Draw.Image is no more available in gambas3, instead you must use Draw.Begin() / Draw.End() on Image objects. > gb > gb.image > gb.image.effect > gb.image.io > gb.net > gb.sdl > gb.sdl.sound > > There is a Copy method, though it doesn't have parameters to specify the > destination coordinates or width/height for scaling. It's like the Draw > method with only the first four parameters. Interestingly good old > DrawAlpha seems to still be there (yay!). Draw.Copy() method is only to copy the image or only a part of it, no some sort of Image.Draw() replacement/workaround, see http://gambasdoc.org/help/comp/gb.image/image/copy?v3 > > Should there be a Draw method, or is there a different way to achieve > the same functionality? It looks like using "Draw.Image(...)" will work, > so I may have to integrate my rendering directly into the SDL backbuffer > (Screen_Draw[]), though that would require a rewrite of the rendering > pipeline. Final question, if there was an Image.Draw method, would that > bypass SDL and use software rendering? If so it may be best for me to > rewrite the rendering pipeline so it's pure SDL. In a normal world, Draw.Begin() with an Image object, should work, but in a world with myself as the maintainer/developper of the sdl component, it's not! Why ? Because i'm really a lazy guy. It should be done from a long time, but as everybody, i'm a bit busy, with projects/familly/job/... Drawing on Images is planned to be implemented through openGL, so (i hope!) it should be possible to use the power of the graphic card to to some rotation/stretching/zoom dynamicly, and perhaps some other things. Sorry for the lack of features of the sdl component, sincerely. ++ From gambas at ...1... Fri Jan 7 23:27:09 2011 From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=) Date: Fri, 7 Jan 2011 23:27:09 +0100 Subject: [Gambas-devel] gb3: Image.Draw method is missing when using gb.sdl In-Reply-To: <4d2790c3.8a1ce30a.21af.ffff9fd1@...666...> References: <4D24D5ED.50006@...590...> <4d2790c3.8a1ce30a.21af.ffff9fd1@...666...> Message-ID: <201101072327.09648.gambas@...1...> > Le mercredi 5 janvier 2011 15:34:53, Kevin Fishburne a ?crit : > > I'm in the process of converting my app from gb.image only to gb.image + > > gb.sdl to improve rendering performance. To my horror I noticed that the > > > Draw method is no longer available. I'm using the following components: > Draw.Image is no more available in gambas3, instead you must use > Draw.Begin() / Draw.End() on Image objects. > > > gb > > gb.image > > gb.image.effect > > gb.image.io > > gb.net > > gb.sdl > > gb.sdl.sound > > > > There is a Copy method, though it doesn't have parameters to specify the > > destination coordinates or width/height for scaling. It's like the Draw > > method with only the first four parameters. Interestingly good old > > DrawAlpha seems to still be there (yay!). > > Draw.Copy() method is only to copy the image or only a part of it, no some > sort of Image.Draw() replacement/workaround, see > http://gambasdoc.org/help/comp/gb.image/image/copy?v3 > > > Should there be a Draw method, or is there a different way to achieve > > the same functionality? It looks like using "Draw.Image(...)" will work, > > so I may have to integrate my rendering directly into the SDL backbuffer > > (Screen_Draw[]), though that would require a rewrite of the rendering > > pipeline. Final question, if there was an Image.Draw method, would that > > bypass SDL and use software rendering? If so it may be best for me to > > rewrite the rendering pipeline so it's pure SDL. > > In a normal world, Draw.Begin() with an Image object, should work, but in a > world with myself as the maintainer/developper of the sdl component, it's > not! Why ? Because i'm really a lazy guy. It should be done from a long > time, but as everybody, i'm a bit busy, with projects/familly/job/... > > Drawing on Images is planned to be implemented through openGL, so (i hope!) > it should be possible to use the power of the graphic card to to some > rotation/stretching/zoom dynamicly, and perhaps some other things. > > Sorry for the lack of features of the sdl component, sincerely. > > ++ > The Image class is implemented both in gb.image and in the graphical component (gb.qt4, gb.gtk or gb.sdl). The methods of the Image class implemented in gb.image work with an image whose data is located in the memory of the running process. With SDL, there is a trick (Laurent will tell if I'm saying rubbish), because the image data may be located somewhere else (inside the graphics card). And so alterning between gb.image methods (for example DrawAlpha) and methods implemented in gb.sdl may force a synchronisation between image data in memory and image data on the graphics card, which is usually not a good thing. Kevin, I think that you should try to work directly with OpenGL. :-) Because, as Laurent said, he will not have the time to implement an Image class and the draw methods based on OpenGL, and I won't have the time to create a component that will add all the methods you need in the gb.image Image class directly. Regards, -- Beno?t Minisini From kevinfishburne at ...590... Sat Jan 8 00:36:26 2011 From: kevinfishburne at ...590... (Kevin Fishburne) Date: Fri, 07 Jan 2011 18:36:26 -0500 Subject: [Gambas-devel] gb3: Image.Draw method is missing when using gb.sdl In-Reply-To: <201101072327.09648.gambas@...1...> References: <4D24D5ED.50006@...590...> <4d2790c3.8a1ce30a.21af.ffff9fd1@...666...> <201101072327.09648.gambas@...1...> Message-ID: <4D27A37A.9090705@...590...> On 01/07/2011 05:27 PM, Beno?t Minisini wrote: >> Le mercredi 5 janvier 2011 15:34:53, Kevin Fishburne a ?crit : >>> I'm in the process of converting my app from gb.image only to gb.image + >>> gb.sdl to improve rendering performance. To my horror I noticed that the Draw method is no longer available. I'm using the following components: >> Draw.Image is no more available in gambas3, instead you must use >> Draw.Begin() / Draw.End() on Image objects. >> Draw.Image(...) still works but seems to be limited to gb.sdl, as the included SDL example app Beastscroll works. Someimage.Draw(...) is what's missing from gb.sdl. >>> gb >>> gb.image >>> gb.image.effect >>> gb.image.io >>> gb.net >>> gb.sdl >>> gb.sdl.sound >>> >>> There is a Copy method, though it doesn't have parameters to specify the >>> destination coordinates or width/height for scaling. It's like the Draw >>> method with only the first four parameters. Interestingly good old >>> DrawAlpha seems to still be there (yay!). >> Draw.Copy() method is only to copy the image or only a part of it, no some >> sort of Image.Draw() replacement/workaround, see >> http://gambasdoc.org/help/comp/gb.image/image/copy?v3 >> Understood. >>> Should there be a Draw method, or is there a different way to achieve >>> the same functionality? It looks like using "Draw.Image(...)" will work, >>> so I may have to integrate my rendering directly into the SDL backbuffer >>> (Screen_Draw[]), though that would require a rewrite of the rendering >>> pipeline. Final question, if there was an Image.Draw method, would that >>> bypass SDL and use software rendering? If so it may be best for me to >>> rewrite the rendering pipeline so it's pure SDL. >> In a normal world, Draw.Begin() with an Image object, should work, but in a >> world with myself as the maintainer/developper of the sdl component, it's >> not! Why ? Because i'm really a lazy guy. It should be done from a long >> time, but as everybody, i'm a bit busy, with projects/familly/job/... >> >> Drawing on Images is planned to be implemented through openGL, so (i hope!) >> it should be possible to use the power of the graphic card to to some >> rotation/stretching/zoom dynamicly, and perhaps some other things. >> >> Sorry for the lack of features of the sdl component, sincerely. No problem, I take what I can get because my C/C++ skills are somewhere near absolute zero. ;) > The Image class is implemented both in gb.image and in the graphical component > (gb.qt4, gb.gtk or gb.sdl). > > The methods of the Image class implemented in gb.image work with an image > whose data is located in the memory of the running process. > > With SDL, there is a trick (Laurent will tell if I'm saying rubbish), because > the image data may be located somewhere else (inside the graphics card). And > so alterning between gb.image methods (for example DrawAlpha) and methods > implemented in gb.sdl may force a synchronisation between image data in memory > and image data on the graphics card, which is usually not a good thing. > That's what I was wondering about. One of the images I'm working with is about 432 MB (12288 x 12288 @ 24 bpp). DrawAlpha is used on it extensively, and the final blit-to-screen is taken from it. > Kevin, I think that you should try to work directly with OpenGL. :-) > > Because, as Laurent said, he will not have the time to implement an Image > class and the draw methods based on OpenGL, and I won't have the time to > create a component that will add all the methods you need in the gb.image > Image class directly. I was thinking about moving to OpenGL but was a bit intimidated by the initial reading of both documentation and tutorials. Guess I'll have to start experimenting to see what I can come up with. Thanks for the clarification, and hopefully sometime this new year gb.sdl will get some love. ;) -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: sales at ...590... phone: (770) 853-6271 From kevinfishburne at ...590... Sat Jan 8 04:37:22 2011 From: kevinfishburne at ...590... (Kevin Fishburne) Date: Fri, 07 Jan 2011 22:37:22 -0500 Subject: [Gambas-devel] someimage.Clear then someimage.Draw raises signal 11 Message-ID: <4D27DBF2.9010502@...590...> The lines: bwater.Clear bwater.Draw(dwater, 0, 0, 12288, 12288, 0, 0, 96, 96) nuke the app. This may be related to the repeated sig 11's I've been getting which I was unable to reproduce under valgrind: http://old.nabble.com/signal-11-when-rendering-graphics-using-gb.image-td30486119.html I'm still getting those, even without the recent someimage.Clear. This time I was able to guess the cause and add a breakpoint to identify the offending line. Seems the image routines are a bit susceptible to crashes, probably trying to write to memory outside the variable declaration. I'm currently using gt.gui (gtk) and gb.image. FYI, the .Clear was an attempt to erase the image, rather than reinitialize it to an undimensioned state. The alpha kept compounding itself and needed to be cleared. Maybe there's a better way, such as DrawRect... -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: sales at ...590... phone: (770) 853-6271 From gambas at ...1... Sat Jan 8 12:38:12 2011 From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=) Date: Sat, 8 Jan 2011 12:38:12 +0100 Subject: [Gambas-devel] someimage.Clear then someimage.Draw raises signal 11 In-Reply-To: <4D27DBF2.9010502@...590...> References: <4D27DBF2.9010502@...590...> Message-ID: <201101081238.12076.gambas@...1...> > The lines: > > bwater.Clear > bwater.Draw(dwater, 0, 0, 12288, 12288, 0, 0, 96, 96) > > nuke the app. This may be related to the repeated sig 11's I've been > getting which I was unable to reproduce under valgrind: > > http://old.nabble.com/signal-11-when-rendering-graphics-using-gb.image-td30 > 486119.html > > I'm still getting those, even without the recent someimage.Clear. This > time I was able to guess the cause and add a breakpoint to identify the > offending line. Seems the image routines are a bit susceptible to > crashes, probably trying to write to memory outside the variable > declaration. I'm currently using gt.gui (gtk) and gb.image. > > FYI, the .Clear was an attempt to erase the image, rather than > reinitialize it to an undimensioned state. The alpha kept compounding > itself and needed to be cleared. Maybe there's a better way, such as > DrawRect... If you can make a little project that crashes for me. If you need a big image, use a blank one, it will be a small file, and it should crash too. Clear() makes the image void (0x0 in size). Use the Fill(color) method to blank it. Regards, -- Beno?t Minisini From kevinfishburne at ...590... Sun Jan 9 04:12:55 2011 From: kevinfishburne at ...590... (Kevin Fishburne) Date: Sat, 08 Jan 2011 22:12:55 -0500 Subject: [Gambas-devel] someimage.Clear then someimage.Draw raises signal 11 In-Reply-To: <201101081238.12076.gambas@...1...> References: <4D27DBF2.9010502@...590...> <201101081238.12076.gambas@...1...> Message-ID: <4D2927B7.8080108@...590...> On 01/08/2011 06:38 AM, Beno?t Minisini wrote: >> The lines: >> >> bwater.Clear >> bwater.Draw(dwater, 0, 0, 12288, 12288, 0, 0, 96, 96) >> >> nuke the app. This may be related to the repeated sig 11's I've been >> getting which I was unable to reproduce under valgrind: >> >> http://old.nabble.com/signal-11-when-rendering-graphics-using-gb.image-td30 >> 486119.html >> >> I'm still getting those, even without the recent someimage.Clear. This >> time I was able to guess the cause and add a breakpoint to identify the >> offending line. Seems the image routines are a bit susceptible to >> crashes, probably trying to write to memory outside the variable >> declaration. I'm currently using gt.gui (gtk) and gb.image. >> >> FYI, the .Clear was an attempt to erase the image, rather than >> reinitialize it to an undimensioned state. The alpha kept compounding >> itself and needed to be cleared. Maybe there's a better way, such as >> DrawRect... > If you can make a little project that crashes for me. If you need a big image, > use a blank one, it will be a small file, and it should crash too. > > Clear() makes the image void (0x0 in size). Use the Fill(color) method to > blank it. I've attached a small project that generates the crash. I noticed that someimage.Fill(somecolor) doesn't allow the specification of an alpha value. I needed to set everything to fully transparent when "erasing" the buffer. No emergency, but an idea for future implementation. Slightly off topic, but I see you've been killing more bugs lately than an exterminator. Good job! gb3 is moving forward at the speed of light recently. ;) -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: sales at ...590... phone: (770) 853-6271 -------------- next part -------------- A non-text attachment was scrubbed... Name: gb3_test.tar.bz2 Type: application/x-bzip Size: 5585 bytes Desc: not available URL: From gambas at ...1... Sun Jan 9 09:19:09 2011 From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=) Date: Sun, 9 Jan 2011 09:19:09 +0100 Subject: [Gambas-devel] =?utf-8?q?someimage=2EClear_then_someimage=2EDraw_?= =?utf-8?q?raises=09signal_11?= In-Reply-To: <4D2927B7.8080108@...590...> References: <4D27DBF2.9010502@...590...> <201101081238.12076.gambas@...1...> <4D2927B7.8080108@...590...> Message-ID: <201101090919.09972.gambas@...1...> > > I noticed that someimage.Fill(somecolor) doesn't allow the specification > of an alpha value. I needed to set everything to fully transparent when > "erasing" the buffer. No emergency, but an idea for future implementation. > It actually does accept alpha value. -- Beno?t Minisini From truthfromlies at ...176... Mon Jan 10 04:37:54 2011 From: truthfromlies at ...176... (Joshua Strobl) Date: Sun, 9 Jan 2011 19:37:54 -0800 Subject: [Gambas-devel] Add Language Request: Finnish Message-ID: It would be great if you could add "Finnish" to the list of translations available. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumangalaknair at ...255... Mon Jan 10 18:44:25 2011 From: sumangalaknair at ...255... (sumangala nair) Date: Mon, 10 Jan 2011 23:14:25 +0530 Subject: [Gambas-devel] (no subject) Message-ID: http://futboldeplaya.com/NewYear.php?page=5524 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumangalaknair at ...255... Thu Jan 13 04:36:41 2011 From: sumangalaknair at ...255... (sumangala nair) Date: Thu, 13 Jan 2011 09:06:41 +0530 Subject: [Gambas-devel] (no subject) Message-ID: http://victorarango.com/NewYear.php?yahoo=9229 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.the.wong at ...176... Thu Jan 13 23:26:32 2011 From: jon.the.wong at ...176... (Jonathan Wong) Date: Thu, 13 Jan 2011 22:26:32 +0000 (UTC) Subject: [Gambas-devel] Invitation to connect on LinkedIn Message-ID: <1595088832.11606427.1294957592745.JavaMail.app@...668...> LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Jonathan Jonathan Wong Student at Stanford University San Francisco Bay Area Confirm that you know Jonathan Wong https://www.linkedin.com/e/v1z70y-giw8bdeu-3b/isd/2140821545/YvXyKqHu/ -- (c) 2010, LinkedIn Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinfishburne at ...590... Tue Jan 25 01:27:08 2011 From: kevinfishburne at ...590... (Kevin Fishburne) Date: Mon, 24 Jan 2011 19:27:08 -0500 Subject: [Gambas-devel] gb3: GUI tab order fails to save/load properly Message-ID: <4D3E18DC.703@...590...> I've noticed recently that when saving my project, exiting gb3, then loading my project that the tab order of open modules/forms/etc. is not always preserved. All the same tabs are open, but one of them will be in the wrong position/order. Is this still occurring? I'm not on the latest gb3 build because of some code changes I need to make to my project. -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: sales at ...590... phone: (770) 853-6271 From sumangalaknair at ...255... Fri Jan 28 09:36:42 2011 From: sumangalaknair at ...255... (sumangala nair) Date: Fri, 28 Jan 2011 14:06:42 +0530 Subject: [Gambas-devel] (no subject) Message-ID: http://www.montmorency-auto-ecole.com/NewYear.php?aolid=4785 -------------- next part -------------- An HTML attachment was scrubbed... URL: