Re: [Gambas-user] Financial program
Doriano Blengino a écrit : ... while only 2% of them want to use financial capabilities. So, that 2% must live with a language not very suitable for accounting. Use long integers, divide them, use format$()... is the reply from Benoit. Does someone remember the Cobol? With a simple declaration picture 99. it created a datatype and managed all the roundings and conversions on that datatype; this was the power of that language. I don't say that Don't burry Cobol too fast: for banking *only*, this year will be around 5 milliards Cobol written lines (progression is an avg of 14% per year). This kinda feature was also stollen from Cobol to be used in dBase, which was a great boost for DBs into programming world. gambas should implement this, but it would not hurt... it is a matter of choice; I understand that this kind of things is difficult to implement (or, who knows... with OO programming... but the really hard part is the mixing of different types in the same expression). I totally agree: this also would make the difference between a nice GUI maker and a mature graphical language. That's what I was trying to explain (with no such fortune though.) The most important application I've written with gambas is something similar to a financial one. I faced problems with gridviews, tableviews, Yeah: THIS is why I don't wanna store other things than decimal(n,n); furthermore, the more you have transformations the less chances you have to avoid bugs (especially sneaky ones). formats, roundings... all the things we are speaking about just now, and they are not yet fully solved. I think that the way you describe is a hard work, even if it is the only possible at the moment. I totally Dorianonize :D JY -- Law of Probable Dispersal: Whatever it is that hits the fan will not be evenly distributed. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Jean-Yves F. Barbier ha scritto: Doriano Blengino a écrit : ... while only 2% of them want to use financial capabilities. So, that 2% must live with a language not very suitable for accounting. Use long integers, divide them, use format$()... is the reply from Benoit. Does someone remember the Cobol? With a simple declaration picture 99. it created a datatype and managed all the roundings and conversions on that datatype; this was the power of that language. I don't say that Don't burry Cobol too fast: for banking *only*, this year will be around 5 milliards Cobol written lines (progression is an avg of 14% per year). This is a proof that well designed things get a long life. Ok, cobol was invented exactly for that purpose - sadness is that nobody else seem to care much about those good things. And money is the gas (citation from a popular rock song :-)) of the world... gambas should implement this, but it would not hurt... it is a matter of choice; I understand that this kind of things is difficult to implement (or, who knows... with OO programming... but the really hard part is the mixing of different types in the same expression). I totally agree: this also would make the difference between a nice GUI maker and a mature graphical language. That's what I was trying to explain (with no such fortune though.) You was more lucky than me, because you was replied perhaps in gambas 4; when was my turn to ask, Benoit replied I will not implement currency type in gambas. Stop. What an irony... someone who hates money and financial programs (me) has to be knocked down for a request about currency... But on the side of the possible implementation in gambas, it is a really hard work. I thought a little about the question, not necessarily to propose changes in gambas, but to solve the problems in my application. A new class, which does rounding and formatting could work. Something like dim subtotal as new currency(4,3) would instantiate a variable with three decimals, stored as a long integer. subtotal.picture would return a string representation, subtotal.picture(12) would return a space-leaded string of 12 characters, with the formatted number aligned to the right. subtotal.multiply() would multiply numbers, and so on. Other methods would be required to interface to databases. This is the OO way to implement what nando suggested. The problem is that calculi would be no more expressed in the usual, plain way, but in an unnatural way: totalinvoice=amount+vat would turn in totalinvoice.set(amount, vat). After the first look, this could be something one can live with. But overloadable operators would be very appreciated to improve readability and, if impossible, compiler macro at least would help. You can walk around the problem as much as you want, and you finish with forcing a language to do things it never was planned to do. The same as complex numbers in C - you can use them, but what a bore! And, in fact, python supports complex numbers natively. I must experiment a little with this idea, but I suspect that new classes for every textual gui element would be needed, and it is this part which scares me. I wrote some new components for this, and they work, but they have some quirks I don't understand well. And... I really hate accounting programs... Uhm... I just readed back the mail about the calculi part. The picturednumber class could evaluate a string... so totalinvoice=amount+vat could be written as totalinvoice.setTo(amount+vat)... double work, but double result... the only problem is that the compiler can not check for the correctness of the expression. Problems again. Regards, Doriano -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Doriano Blengino a écrit : Don't burry Cobol too fast: for banking *only*, this year will be around 5 milliards Cobol written lines (progression is an avg of 14% per year). This is a proof that well designed things get a long life. Ok, cobol was invented exactly for that purpose - sadness is that nobody else seem to care much about those good things. And money is the gas (citation from a popular rock song :-)) of the world... This isn't really true: part of my family owns a company that sell pastry products (additives etc), their ERP run under UNIX and VT100 consoles and is entirely written in Cobol. Many mid to large companies use Cobol, and have problems to find programmers interested into this language - so there are good days left for those who care. ADA is also growing because of its very specialized variable definitions possibilities. ... You was more lucky than me, because you was replied perhaps in gambas 4; when was my turn to ask, Benoit replied I will not implement currency type in gambas. Stop. What an irony... someone who hates money and financial programs (me) has to be knocked down for a request about currency... I don't like it either, but there are places to take with good programs. But on the side of the possible implementation in gambas, it is a really hard work. I thought a little about the question, not necessarily to propose changes in gambas, but to solve the problems in my application. A new class, which does rounding and formatting could work. Something like dim subtotal as new currency(4,3) would instantiate a variable with three decimals, stored as a long integer. subtotal.picture would return a string representation, subtotal.picture(12) would return a space-leaded string of 12 characters, with the formatted number aligned to the right. subtotal.multiply() would multiply numbers, and so on. Other methods would be required to interface to databases. This is the OO way to implement what nando suggested. The problem is that calculi would be no more expressed in the usual, plain way, but in an unnatural way: totalinvoice=amount+vat would turn in totalinvoice.set(amount, vat). After the first look, this could be something one can live with. But overloadable operators would be very appreciated to improve readability and, if impossible, compiler macro at least would help. You can walk around the problem as much as you want, and you finish with forcing a language to do things it never was planned to do. The same as complex numbers in C - you can use them, but what a bore! And, in fact, python supports complex numbers natively. This is even more complicated - ie: fr law say that precision of VAT rates is 4 decimals, and as I said before, some items can be invoiced with a large number of decimals. For VAT, more than 2 decimals had never been used but could be tomorrow; so this is an entire int2decimal processor to write (as you wrote, no more than 2 members to multiply because of that:( I must experiment a little with this idea, but I suspect that new classes for every textual gui element would be needed, and it is this part which scares me. I wrote some new components for this, and they work, but they have some quirks I don't understand well. And... I really hate accounting programs... Uhm... I just readed back the mail about the calculi part. The picturednumber class could evaluate a string... so totalinvoice=amount+vat could be written as totalinvoice.setTo(amount+vat)... double work, but double result... the only problem is that the compiler can not check for the correctness of the expression. Problems again. I lost too much time with things like that and now strongly consider to interface all calculation to Python and only keep GB as a GUI. This shouldn't add that many things to the system: as of Linux, Python is a std install, as of Debian, this will only require a few packages to add (AND it'll solve docs templates, PDF generation and some other dead-ends) Regards, JY -- Don't get even -- get odd! -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Doriano Blengino schrieb: nando ha scritto: My contribution to this conversation is.. Always INT or LONG for money. Keep a global variable to divide by (for example 2 decimal places) 100 when printing/displaying things to humans... -OR- to take the string and insert a period for cents (North America) Make a really nice SUB to return a formatted string is good. It is the utmost importance not to use FLOAT from the beginning because calculations will be wrong after a while and it will not balance. You will have headaches!!! You are perfectly true. It seems that floating point does not like base 10 numbers... :-) But here comes in place the power of a programming language; a good language is a wrapper around bad or annoying things. All we love gambas because it is easy to construct user interface. But there would be no necessity of its power - one can write external functions and interface to X11 directly... So when you tell me don't use floats for accounting I agree. When you say use a global variable to divide, insert a decimal point and so on, I think 100% of gambas users want to use graphical interfaces, while only 2% of them want to use financial capabilities. So, that 2% must live with a language not very suitable for accounting. Use long integers, divide them, use format$()... is the reply from Benoit. Does someone remember the Cobol? With a simple declaration picture 99. it created a datatype and managed all the roundings and conversions on that datatype; this was the power of that language. I don't say that gambas should implement this, but it would not hurt... it is a matter of choice; I understand that this kind of things is difficult to implement (or, who knows... with OO programming... but the really hard part is the mixing of different types in the same expression). The most important application I've written with gambas is something similar to a financial one. I faced problems with gridviews, tableviews, formats, roundings... all the things we are speaking about just now, and they are not yet fully solved. I think that the way you describe is a hard work, even if it is the only possible at the moment. Regards, Hi I remember Cobol, it was very much used in the 80'es, and the company in which I was employed at that time used it for all commercial software. Then C got more and more modern to use, and one had to write a lot of functions to get the same results - in the accounting-context. Cobol had its own database, just datafiles, it did not have to convert anything from any SQL-Server, and as far as I can remember, it stored the data without any floats - the picture 9.99 just told it where to set the decimalpoint. regards -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Jean-Yves F. Barbier ha scritto:
Doriano Blengino a écrit :
Don't burry Cobol too fast: for banking *only*, this year will be around
5 milliards Cobol written lines (progression is an avg of 14% per year).
This is a proof that well designed things get a long life. Ok, cobol was
invented exactly for that purpose - sadness is that nobody else seem to
care much about those good things. And money is the gas (citation from a
popular rock song :-)) of the world...
This isn't really true: part of my family owns a company that sell pastry
products (additives etc), their ERP run under UNIX and VT100 consoles
and is entirely written in Cobol.
Many mid to large companies use Cobol, and have problems to find programmers
interested into this language - so there are good days left for those who
care.
I was intending that nobody steals good ideas from cobol. I know that
cobol is still used but, I think, it is an old language. Dream: a really
good language having some properties of cobol, and specialized GUI
widgets where you bind the variable (with picture, limits, precision and
so on) to a widget. Probably Java and Python are already able to do so,
but they have other limits. Another problem I often face is that of
preferences. I make a nicely customizable program, with lot of
preferences, and for every preference I have to put a widget on a form,
load its content from a file, rewrite its content to the file, and so
on. Simply boring.
ADA is also growing because of its very specialized variable definitions
possibilities.
A strongness inherited from pascal... I gave a look to many, countless
languages, and only few met my own requirements - strong typization,
good compiler checks, overloading and, of course!, OO model. One of
these was Ada. But I rejected all C- and Java- flavoured. Irony again...
C language is the one I use most...
But on the side of the possible implementation in gambas, it is a really
hard work. I thought a little about the question, not necessarily to
propose changes in gambas, but to solve the problems in my application.
A new class, which does rounding and formatting could work. Something
like dim subtotal as new currency(4,3) would instantiate a variable
with three decimals, stored as a long integer. subtotal.picture would
return a string representation, subtotal.picture(12) would return a
space-leaded string of 12 characters, with the formatted number aligned
to the right. subtotal.multiply() would multiply numbers, and so on.
Other methods would be required to interface to databases.
This is the OO way to implement what nando suggested. The problem is
that calculi would be no more expressed in the usual, plain way, but in
an unnatural way: totalinvoice=amount+vat would turn in
totalinvoice.set(amount, vat). After the first look, this could be
something one can live with. But overloadable operators would be very
appreciated to improve readability and, if impossible, compiler macro at
least would help. You can walk around the problem as much as you want,
and you finish with forcing a language to do things it never was planned
to do. The same as complex numbers in C - you can use them, but what a
bore! And, in fact, python supports complex numbers natively.
This is even more complicated - ie: fr law say that precision of VAT rates
is 4 decimals, and as I said before, some items can be invoiced with a
large number of decimals.
For VAT, more than 2 decimals had never been used but could be tomorrow;
so this is an entire int2decimal processor to write (as you wrote, no more
than 2 members to multiply because of that:(
I am not sure to understand. If you take an amount with 2 decimals of
precision, you can calculate VAT with 4 decimal precision:
dim amount as new currency(8,2)
dim vatrate as new currency(2,4)
dim vat as new currency(8,2)
dim total as new currency(8,2)
amount.calculate()
vatrate.set(18.55) ' is this a percent, right?
vat.calculate(amount % vatrate)
total.calculate('amount+vat')
Now a few things should be considered. The variable VAT has a precision
of 2 decimals, but by invoking vat.calculate(...), a variable with
precision 4 is passed in, so the calculus is made on 4 decimals and,
just before storing the result to VAT, the rounding to 2 decimals is
made (and the rounding is another interesting piece...).
So we should have what we want: precision 4 in the rate, and precision 2
in money's variables. Not sure what to do in the inverse operation...
taking out a 18.55% vat rate from a total, should give a correct amount
and vat which, added together, should give the total again... funny to
say, but a little harder to implement... but this could be just another
method (I call it scorporo, but I don't know how to say it in english).
Uhm... I just readed back the mail about the calculi part. The
picturednumber
Re: [Gambas-user] Financial program
Doriano Blengino a écrit : ... A strongness inherited from pascal... I gave a look to many, countless hmm, I don't think Pascal can define vars as temperature[-10, +50] languages, and only few met my own requirements - strong typization, good compiler checks, overloading and, of course!, OO model. One of these was Ada. But I rejected all C- and Java- flavoured. Irony again... C language is the one I use most... Yes this is the PB, each one has pros cons. ... I lost too much time with things like that and now strongly consider to interface all calculation to Python and only keep GB as a GUI. Betrayer! :-))) No, this meets what you said above: no language is perfect, so the only solution is to take whatever you want in some of them (well, not some, 2) And I'm not a language integrist: I pick what fits my needs. Why not interface to cobol directly, then? I don't think your way is viable - it would be even more forcing a language to do things it never was planned for. I think you intend to call /usr/lib/libpython2.xx, perhaps through some wrapper class; interesting... may be this could solve the expressions issue... I'm far from a specialist, as a matter of fact I didn't used OO before (only C and ASM a looong time ago) so the only way I see to make a mix is to call external subroutines through SHELL or EXEC; but if you know other ways, I'm in. I don't wanna end up with terrible hacks, nor spend more time to develop something that already exists in another language: I need it to run the way I want in an easy (and maintenable) way - without headaches... Regards JY -- You are here: *** *** * *** * *** * But you're not all there. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Jean-Yves F. Barbier ha scritto: Doriano Blengino a écrit : ... A strongness inherited from pascal... I gave a look to many, countless hmm, I don't think Pascal can define vars as temperature[-10, +50] What do you mean precisely? Can you define the properties of such variable? I'm far from a specialist, as a matter of fact I didn't used OO before (only C and ASM a looong time ago) so the only way I see to make a mix is to call external subroutines through SHELL or EXEC; but if you know other ways, I'm in. I don't wanna end up with terrible hacks, nor spend more time to develop something that already exists in another language: I need it to run the way I want in an easy (and maintenable) way - without headaches... *That* would be slow, very slooow. There are external declarations in gambas (I was admired when I saw them the first time). That should be the way to go. I used them to interface the LDAP library, and it worked. But it was a pain to manage pointers and memory in gambas, and probably there are several quirks in that work. If the python lib is written in C++ instead, then things get worse, so an EXEC is simpler for sure (but slow). I insist on the slowness because you insisted on that in an earlier mail. If you want to process thousands rows from a database, then the exec is guaranteed to be out of discussion. Regards, Doriano -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
2009/12/15 Doriano Blengino doriano.bleng...@fastwebnet.it: Jean-Yves F. Barbier ha scritto: Doriano Blengino a écrit : ... A strongness inherited from pascal... I gave a look to many, countless hmm, I don't think Pascal can define vars as temperature[-10, +50] What do you mean precisely? Can you define the properties of such variable? I'm far from a specialist, as a matter of fact I didn't used OO before (only C and ASM a looong time ago) so the only way I see to make a mix is to call external subroutines through SHELL or EXEC; but if you know other ways, I'm in. I don't wanna end up with terrible hacks, nor spend more time to develop something that already exists in another language: I need it to run the way I want in an easy (and maintenable) way - without headaches... *That* would be slow, very slooow. There are external declarations in gambas (I was admired when I saw them the first time). That should be the way to go. I used them to interface the LDAP library, and it worked. But it was a pain to manage pointers and memory in gambas, and probably there are several quirks in that work. If the python lib is written in C++ instead, then things get worse, so an EXEC is simpler for sure (but slow). I insist on the slowness because you insisted on that in an earlier mail. If you want to process thousands rows from a database, then the exec is guaranteed to be out of discussion. And on the thouthen of accounting program code i've readen the majority use long or integer to store values. so they use integer to compute and in the database they store the printable value as string... Not many are using float, and those are beginner's ones... like mine :/ lol Regards, Doriano -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
I don't like floats. They are slow, and bitchy; Dim n As Single n = 1.4 - 0.2 Print n And the result is 1.20047684, which is obviously wrong from math point of view. Correcting floating point artifact, makes floats even slower. And it is surprisingly common to be able to use integers instead. Jussi On Tue, Dec 15, 2009 at 15:30, Fabien Bodard gambas...@gmail.com wrote: 2009/12/15 Doriano Blengino doriano.bleng...@fastwebnet.it: Jean-Yves F. Barbier ha scritto: Doriano Blengino a écrit : ... A strongness inherited from pascal... I gave a look to many, countless hmm, I don't think Pascal can define vars as temperature[-10, +50] What do you mean precisely? Can you define the properties of such variable? I'm far from a specialist, as a matter of fact I didn't used OO before (only C and ASM a looong time ago) so the only way I see to make a mix is to call external subroutines through SHELL or EXEC; but if you know other ways, I'm in. I don't wanna end up with terrible hacks, nor spend more time to develop something that already exists in another language: I need it to run the way I want in an easy (and maintenable) way - without headaches... *That* would be slow, very slooow. There are external declarations in gambas (I was admired when I saw them the first time). That should be the way to go. I used them to interface the LDAP library, and it worked. But it was a pain to manage pointers and memory in gambas, and probably there are several quirks in that work. If the python lib is written in C++ instead, then things get worse, so an EXEC is simpler for sure (but slow). I insist on the slowness because you insisted on that in an earlier mail. If you want to process thousands rows from a database, then the exec is guaranteed to be out of discussion. And on the thouthen of accounting program code i've readen the majority use long or integer to store values. so they use integer to compute and in the database they store the printable value as string... Not many are using float, and those are beginner's ones... like mine :/ lol Regards, Doriano -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Jean-Yves F. Barbier ha scritto: Doriano Blengino a écrit : A strongness inherited from pascal... I gave a look to many, countless hmm, I don't think Pascal can define vars as temperature[-10, +50] What do you mean precisely? Can you define the properties of such variable? means: var name of type = temperature, type = integer, can't go further its boundaries [-10, +50] ([-10.0, +50.0] would have a 1/10th degree precision and so on) Pascal can do it on scalars: type Tdegrees = -10..50;. The storage will be the minimum required (in this case, a shortint, or signed byte). If you turn range checking on, then assigning a value out of range raises a runtime error. If in your program you have such a wrong assignment from a constant expression, then the error will be detected at compile time (ie, the compiler is smart enough to detect this). This is the old, standard pascal, where you can't do the same with real (floating) numbers because they are not scalar, so by definition they do not have ranges, so you can not define subranges (and this is a limit, dictated by pureness of original pascal). I think that ADA's very advanced declarations started from here, adding more capabilities (pascal has the same age as C). In more recent pascal you can overload everything (operators included), so you can get a step ahead; but temperature := temperature+1 always means increment of one unit. This is what is possible without OO. Using OO, you must instantiate every variable (because now they are objects), write methods and overload assignments and operators, and make exactly what you want even with precision 1/10th: writing temperature := temperature+1 can lead to 1 degree of increment, or 1 tenth of degree: it depends on how you implement it. Regards, Doriano -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Hi, thank you for all the information. I also found a system made in Finland using PHP. It is called pupesoft and it's web-address is http://www.devlab.fi/pupesoft So now when I have time I will test all of these and see how they work. Best Regards Kari -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
you have Laurux at http://laurux.fr/ but the code is not perfect has it was on the start a code learning programme.. but at the end it's a true accounting program... in french (Gb2) 2009/12/14 Kari Laine klai...@gmail.com: Hi, I have already done little billing program for my parents little firm. It was a learning exercise. It would make a big help to get little companies to move to Linux if there was a financial program that run on Linux and would be free. There comes in Gambas. Is there already an GPLed financial program made with Gambas? If not is someone having different parts of a system willing to donate source code under GPL? My billing program is so horrible that in it's condition I don't want to show it's sources to anyone... it was my first Gambas program... Why Gambas would be extra value for this kind of a project.? Gambas is easy language and integrated editor makes it very easy to implement user interface. Speed and other things which are good in C or C++ are not so important. Naturally someone says Python would be way to go but I find it more difficult than Gambas. Idea is that regular Joe with little experimenting could change the program. Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Fabien Bodard a écrit : you have Laurux at http://laurux.fr/ but the code is not perfect has it was on the start a code learning programme.. but at the end it's a true accounting program... in french (Gb2) BTW, do you plan to have an equivalent of postgresql or python decimal(n,n) into GB3? It would be *very* interesting (otherwise you have to filter every line through Format$) JY -- My rackets are run on strictly American lines, and they're going to stay that way. -- Al Capone -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
On 14/12/09 23:32, Kari Laine wrote: Hi, I have already done little billing program for my parents little firm. It was a learning exercise. It would make a big help to get little companies to move to Linux if there was a financial program that run on Linux and would be free. There comes in Gambas. Is there already an GPLed financial program made with Gambas? If not is someone having different parts of a system willing to donate source code under GPL? My billing program is so horrible that in it's condition I don't want to show it's sources to anyone... it was my first Gambas program... Why Gambas would be extra value for this kind of a project.? Gambas is easy language and integrated editor makes it very easy to implement user interface. Speed and other things which are good in C or C++ are not so important. Naturally someone says Python would be way to go but I find it more difficult than Gambas. Idea is that regular Joe with little experimenting could change the program. Best Regards Kari There is Quasar from Linux Canada. It is very similar to MYOB. Their last GPL version is 1.4.7, I think. After that they went sort of proprietary(Note1) but the documentation of how to hook into the new version database is exemplary. We use 1.4.7, mostly the inventory control part which is excellent. In this version the reporting bits are suboptimal but the rest is fine. We use it since around 2002, using mostly the inventory control part. The mailing list support is excellent. I had studied their source code. It is extremely well written, I learned a lot from it. If you think you can write a decent accounting program in 3 man months you don't know what the task is. If you think you can write a decent accounting program in 3 man years you may have something fairly basic to show but only if you got your priorities right. Accounting programs are very much underestimated. You might just want to hook into what's there and be efficient. The interface is well documented. Regards Werner Note 1: If I recall it properly it was after someone claimed their software was actually his -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Fabien Bodard a écrit : you have Laurux at http://laurux.fr/ but the code is not perfect has it was on the start a code learning programme.. but at the end it's a true accounting program... in french (Gb2) BTW, do you plan to have an equivalent of postgresql or python decimal(n,n) into GB3? It would be *very* interesting (otherwise you have to filter every line through Format$) JY You mean a fixed-point decimal datatype? Or a currency datatype? It cannot be done in Gambas 3. So, in Gambas 4 ? -- Benoît Minisini -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Hi, There is Quasar from Linux Canada. It is very similar to MYOB. Their last GPL version is 1.4.7, I think. Do you have the source for the GPL version. I visited their site and couldn't find it. If you think you can write a decent accounting program in 3 man months you don't know what the task is. If you think you can write a decent accounting program in 3 man years you may have something fairly basic to show but only if you got your priorities right. I always have my priorities wrong ... I am right now swamped. But I was more on the line what exists and could be modified for Finnish market. And idea was also that I wouldn't have to do everything myself. Accounting programs are very much underestimated. I agree. Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Hi, thanks On Mon, Dec 14, 2009 at 6:03 PM, Fabien Bodard gambas...@gmail.com wrote: you have Laurux at http://laurux.fr/ but the code is not perfect has it was on the start a code learning programme.. but at the end it's a true accounting program... in french (Gb2) I don't read a single word French so I have to pass. It would be too difficult for me to adapt. Best Regards Kari -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Benoît Minisini a écrit : Fabien Bodard a écrit : you have Laurux at http://laurux.fr/ but the code is not perfect has it was on the start a code learning programme.. but at the end it's a true accounting program... in french (Gb2) BTW, do you plan to have an equivalent of postgresql or python decimal(n,n) into GB3? It would be *very* interesting (otherwise you have to filter every line through Format$) JY You mean a fixed-point decimal datatype? Or a currency datatype? A fixed-point decimal It cannot be done in Gambas 3. So, in Gambas 4 ? Hu? That's too bad because it is needed to ease accounting purposes. -- Antique fairy tale: Little Red Riding Hood. Modern fairy tale: Oswald, acting alone, shot Kennedy. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Kari Laine a écrit : Hi, thanks On Mon, Dec 14, 2009 at 6:03 PM, Fabien Bodard gambas...@gmail.com wrote: you have Laurux at http://laurux.fr/ but the code is not perfect has it was on the start a code learning programme.. but at the end it's a true accounting program... in french (Gb2) I don't read a single word French so I have to pass. It would be too difficult for me to adapt. You can take a look at sql-ledger that implements a double-entry accounting with many accounting plans (but it is written in perl...) -- A man without a woman is like a fish without gills. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
On 15/12/09 01:22, Kari Laine wrote: Hi, There is Quasar from Linux Canada. It is very similar to MYOB. Their last GPL version is 1.4.7, I think. Do you have the source for the GPL version. I visited their site and couldn't find it. If you think you can write a decent accounting program in 3 man months you don't know what the task is. If you think you can write a decent accounting program in 3 man years you may have something fairly basic to show but only if you got your priorities right. I always have my priorities wrong ... I am right now swamped. But I was more on the line what exists and could be modified for Finnish market. And idea was also that I wouldn't have to do everything myself. Accounting programs are very much underestimated. I agree. Best Regards Kari It's here: ftp://www.linuxcanada.com/pub/Quasar/1.4.7/ I hope to have conveyed: They are very decent people and it is brilliant software. Regards Werner -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
You have the wonderfull accounting programm www.laurus.fr Here you have some : http://gambas.sourceforge.net/en/main.html enjoy :) Henri -- From: Kari Laine klai...@gmail.com Sent: Monday, December 14, 2009 4:32 PM To: Gambas-user@lists.sourceforge.net Subject: [Gambas-user] Financial program Hi, I have already done little billing program for my parents little firm. It was a learning exercise. It would make a big help to get little companies to move to Linux if there was a financial program that run on Linux and would be free. There comes in Gambas. Is there already an GPLed financial program made with Gambas? If not is someone having different parts of a system willing to donate source code under GPL? My billing program is so horrible that in it's condition I don't want to show it's sources to anyone... it was my first Gambas program... Why Gambas would be extra value for this kind of a project.? Gambas is easy language and integrated editor makes it very easy to implement user interface. Speed and other things which are good in C or C++ are not so important. Naturally someone says Python would be way to go but I find it more difficult than Gambas. Idea is that regular Joe with little experimenting could change the program. Best Regards Kari -- PIC - ARM - Microcontrollers - I2C - SPI Keypads - USB-RS232 - USB-I2C - Accessories http://www.byvac.com I am just a happy customer -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Kari Laine wrote: Hi, I have already done little billing program for my parents little firm. It was a learning exercise. It would make a big help to get little companies to move to Linux if there was a financial program that run on Linux and would be free. There comes in Gambas. Is there already an GPLed financial program made with Gambas? If not is someone having different parts of a system willing to donate source code under GPL? My billing program is so horrible that in it's condition I don't want to show it's sources to anyone... it was my first Gambas program... Why Gambas would be extra value for this kind of a project.? Gambas is easy language and integrated editor makes it very easy to implement user interface. Speed and other things which are good in C or C++ are not so important. Naturally someone says Python would be way to go but I find it more difficult than Gambas. Idea is that regular Joe with little experimenting could change the program. Best Regards Kari Hi, Whilst obviously not written in Gambas, I've been using GnuCash for personal accounting for some time. The double entry bit and UI are a little clunky for my basic needs, but in the end it works. I'm think you can use it for billing and you can tailor reports etc in guile, so it may be worth a look. Source code should be available since it is GPL. Tony.. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Benoît Minisini a écrit : Benoît Minisini a écrit : Fabien Bodard a écrit : you have Laurux at http://laurux.fr/ but the code is not perfect has it was on the start a code learning programme.. but at the end it's a true accounting program... in french (Gb2) BTW, do you plan to have an equivalent of postgresql or python decimal(n,n) into GB3? It would be *very* interesting (otherwise you have to filter every line through Format$) JY You mean a fixed-point decimal datatype? Or a currency datatype? A fixed-point decimal It cannot be done in Gambas 3. So, in Gambas 4 ? Hu? That's too bad because it is needed to ease accounting purposes. Why not storing currencies in cents, or fraction of cents, with a Long datatype? No, this is the best way to make mistakes (ie: invoice hardware with 2 decimals, but invoice telephone seconds with 8 connections w/ 3 or 4 on the same invoice, oeuf corse). Format$ is not very useful because of conversions it involves. Using integer arithmetics is muuuch tooo slooow. So the less worse is still Format$. -- Mieux vaut tard que jamais! [ Better late than never ] -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Benoît Minisini a écrit : Benoît Minisini a écrit : Fabien Bodard a écrit : you have Laurux at http://laurux.fr/ but the code is not perfect has it was on the start a code learning programme.. but at the end it's a true accounting program... in french (Gb2) BTW, do you plan to have an equivalent of postgresql or python decimal(n,n) into GB3? It would be *very* interesting (otherwise you have to filter every line through Format$) JY You mean a fixed-point decimal datatype? Or a currency datatype? A fixed-point decimal It cannot be done in Gambas 3. So, in Gambas 4 ? Hu? That's too bad because it is needed to ease accounting purposes. Why not storing currencies in cents, or fraction of cents, with a Long datatype? No, this is the best way to make mistakes (ie: invoice hardware with 2 decimals, but invoice telephone seconds with 8 connections w/ 3 or 4 on the same invoice, oeuf corse). Format$ is not very useful because of conversions it involves. Using integer arithmetics is muuuch tooo slooow. So the less worse is still Format$. I think you are mixing a lot of different things: - When storing a amount of money in memory, you store it in a Long integer in 1/10th of cents. For example, storing 1234,56€ will be stored as 1234560. - When displaying an amount of money, you use Format$(), or your own function. - When getting an amount of money from the user, you have to convert a string into an amount of 1/10th of cents. - When getting an amount of money from the outside, or exporting an amount of money to the outside, you must use an standard exchange format based on a string. So I don't see any problem with that. Why are you talking about telephone seconds? We are talking about money, aren't we? Or there is something I didn't understand? -- Benoît Minisini -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial Program
1. Accounting programs are very much underestimated. That's true, indeed. I know a lot of people who thought that accounting was a minor matter, bought some program and did something not knowing what they did. They all got big problems with the tax authorities. 2. Writing an accounting program is even worse. In accounting, there are so many VAT and income tax questions involved (that change almost daily). If you write an accounting program, you *really* have to know all the tax backgrounds. Which are different from country to country, of course. Beware! Matti -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Benoît Minisini a écrit : ... I think you are mixing a lot of different things: - When storing a amount of money in memory, you store it in a Long integer in 1/10th of cents. For example, storing 1234,56€ will be stored as 123456 I'm gonna test that, but it implies more load of the DB server side to convert from one format to the other. - When displaying an amount of money, you use Format$(), or your own function. - When getting an amount of money from the user, you have to convert a string into an amount of 1/10th of cents. - When getting an amount of money from the outside, or exporting an amount of money to the outside, you must use an standard exchange format based on a string. This is not acceptable: DB must be able to directly process numbers, not to loose 95% of the time to convert a string to a number and vice versa (many of my process aren't done by GB but into stored procedures) So I don't see any problem with that. Why are you talking about telephone seconds? We are talking about money, aren't we? Or there is something I didn't understand? Yep, but some amounts can have many more decimals than others (in telephony, seconds are usually invoiced with @ least 6 decimals and sometimes 8), so mixing that with other number of decimals isn't easy. This is why definable decimals numbers are so important. -- Q: How do you keep a moron in suspense? -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
Benoît Minisini a écrit : ... I think you are mixing a lot of different things: - When storing a amount of money in memory, you store it in a Long integer in 1/10th of cents. For example, storing 1234,56€ will be stored as 123456 I'm gonna test that, but it implies more load of the DB server side to convert from one format to the other. - When displaying an amount of money, you use Format$(), or your own function. - When getting an amount of money from the user, you have to convert a string into an amount of 1/10th of cents. - When getting an amount of money from the outside, or exporting an amount of money to the outside, you must use an standard exchange format based on a string. This is not acceptable: DB must be able to directly process numbers, not to loose 95% of the time to convert a string to a number and vice versa (many of my process aren't done by GB but into stored procedures) Outside means out of your control, or out of the program internals. If it is a stored procedure you wrote, it will manipulate the integer values directly of course. But if you have to send or receive currencies from another program, you must use a standard exchange format. So I don't see any problem with that. Why are you talking about telephone seconds? We are talking about money, aren't we? Or there is something I didn't understand? Yep, but some amounts can have many more decimals than others (in telephony, seconds are usually invoiced with @ least 6 decimals and sometimes 8), so mixing that with other number of decimals isn't easy. This is why definable decimals numbers are so important. Again we are talking about currencies. What's the matter with telephony seconds? If you want to say that you have to store 1/1000th of cents, ro more, just choose a more precise format. With a Long datatype and using 1/100th of currency unit (!), you can store up to 4,6 x 10^12 units. That should be enough. -- Benoît Minisini -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
On Monday 14 December 2009, Jean-Yves F. Barbier wrote: Benoît Minisini a écrit : ... I think you are mixing a lot of different things: - When storing a amount of money in memory, you store it in a Long integer in 1/10th of cents. For example, storing 1234,56€ will be stored as 123456 I'm gonna test that, but it implies more load of the DB server side to convert from one format to the other. It is not a matter of the DB server to calculate. Its the presentation only, the matter of the frontend program. Adding integers a amount in 1/10th of cents stored is more quick then adding floating point numbers that must be handled to and back from the co-processor. In fact your gambas program does not use that co-proc but a library to do the job in software in most cases. Only special programs handle this arithmetic direct to the co-proc. - When displaying an amount of money, you use Format$(), or your own function. - When getting an amount of money from the user, you have to convert a string into an amount of 1/10th of cents. - When getting an amount of money from the outside, or exporting an amount of money to the outside, you must use an standard exchange format based on a string. This is not acceptable: DB must be able to directly process numbers, not to loose 95% of the time to convert a string to a number and vice versa (many of my process aren't done by GB but into stored procedures) A DB server is _just_ losing time if the numbers are in floats and not in integer. It have to first normalize the numbers before it can do the arithmetics. And I'm almost on safe that it also _just_ use a slow library instead of the co-proc. So I don't see any problem with that. Why are you talking about telephone seconds? We are talking about money, aren't we? Or there is something I didn't understand? Yep, but some amounts can have many more decimals than others (in telephony, seconds are usually invoiced with @ least 6 decimals and sometimes 8), so mixing that with other number of decimals isn't easy. Almost every accounting program works with at least 8 decimals for the fractional part. Only at the last step, the presentation the rounding to 2 decimals for currency is/should done. This is why definable decimals numbers are so important. I do agree it can be handy to have but there is no absolute need. However if we talking about scientific calculations then it would/can be a complete different case. In my view a database is for storage of information/numbers. The handling/calculation of the stored data is the job for the end application. In my good old times I made some floating point programs on a Z80 CPU. No support for floats or co-procs available (or acceptable price). I did just what Benoit suggest and worked with 1/100 of a cent and at the last step the round to 2 decimals in Dutch Giuilder. Later I got a request to implement the co-proc and the customer was disapointed about the drop in speed as result. The max bit size was 16 bit for add/subtract so I had to make my own routines for 4 times 16 bit wide. Was interesting job to do. Anyway I feel a bit with your for the request. It can make simple apps more ease to develop. Best regards, Ron_1st -- 111.11 x 111.11 = 12345.678987654321 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
On Tuesday 15 December 2009, Benoît Minisini wrote: Again we are talking about currencies. What's the matter with telephony seconds? If you want to say that you have to store 1/1000th of cents, ro more, just choose a more precise format. With a Long datatype and using 1/100th of currency unit (!), you can store up to 4,6 x 10^12 units. That should be enough. Thanks for the calculation. I hope never have to pay that amount :) :) Best regards, Ron_1st -- 111.11 x 111.11 = 12345.678987654321 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
My contribution to this conversation is.. Always INT or LONG for money. Keep a global variable to divide by (for example 2 decimal places) 100 when printing/displaying things to humans... -OR- to take the string and insert a period for cents (North America) Make a really nice SUB to return a formatted string is good. It is the utmost importance not to use FLOAT from the beginning because calculations will be wrong after a while and it will not balance. You will have headaches!!! -Fernando -- Original Message --- From: Ron_1st ron...@tiscali.nl To: gambas-user@lists.sourceforge.net Sent: Tue, 15 Dec 2009 00:38:35 +0100 Subject: Re: [Gambas-user] Financial program On Tuesday 15 December 2009, Benoît Minisini wrote: Again we are talking about currencies. What's the matter with telephony seconds? If you want to say that you have to store 1/1000th of cents, ro more, just choose a more precise format. With a Long datatype and using 1/100th of currency unit (!), you can store up to 4,6 x 10^12 units. That should be enough. Thanks for the calculation. I hope never have to pay that amount :) :) Best regards, Ron_1st -- 111.11 x 111.11 = 12345.678987654321 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user --- End of Original Message --- -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Financial program
nando ha scritto: My contribution to this conversation is.. Always INT or LONG for money. Keep a global variable to divide by (for example 2 decimal places) 100 when printing/displaying things to humans... -OR- to take the string and insert a period for cents (North America) Make a really nice SUB to return a formatted string is good. It is the utmost importance not to use FLOAT from the beginning because calculations will be wrong after a while and it will not balance. You will have headaches!!! You are perfectly true. It seems that floating point does not like base 10 numbers... :-) But here comes in place the power of a programming language; a good language is a wrapper around bad or annoying things. All we love gambas because it is easy to construct user interface. But there would be no necessity of its power - one can write external functions and interface to X11 directly... So when you tell me don't use floats for accounting I agree. When you say use a global variable to divide, insert a decimal point and so on, I think 100% of gambas users want to use graphical interfaces, while only 2% of them want to use financial capabilities. So, that 2% must live with a language not very suitable for accounting. Use long integers, divide them, use format$()... is the reply from Benoit. Does someone remember the Cobol? With a simple declaration picture 99. it created a datatype and managed all the roundings and conversions on that datatype; this was the power of that language. I don't say that gambas should implement this, but it would not hurt... it is a matter of choice; I understand that this kind of things is difficult to implement (or, who knows... with OO programming... but the really hard part is the mixing of different types in the same expression). The most important application I've written with gambas is something similar to a financial one. I faced problems with gridviews, tableviews, formats, roundings... all the things we are speaking about just now, and they are not yet fully solved. I think that the way you describe is a hard work, even if it is the only possible at the moment. Regards, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
