Gambas

Hey ,friend  I find a site to sell electronic products with very good price. Laptop ,iPhone even Motorcycle are very popular .their products are original quality with very low price as wholesale business supplier.They also can do retail business for end user now. maybe it is fit for your business . if you like you can contact them :   wholesalers-electronic.com  <br>E-mail:  wholesaler318(at)188.com<br>Msn : wholesaler31888(at)hotmail.com<br>

> G'day,
> 
> I implemented a change in the gambas2 IDE. I have two questions:
> 
> 1) Do you want it?
> 2) If so, how do I get it to you?
> 
> The tab implements the X11 colour names. Duplicate colour values have
> been removed.
> 

Wouldn't it better to implement such a thing into the gb.form ColorChooser 
control directly? It is more difficult, as you must find a GUI that is not too 
disturbing. But all programs choosing color will benefit from this - Even if 
personnaly, I've never used X11 colour names in my entire life. :-)

And, more important, you should better develop on Gambas 3 than Gambas 2. I 
mean, I won't merge a change in Gambas 2 if I don't have the equivalent for 
Gambas 3.

If you agree, tell me, I will grant you a write access to the svn repository.

Regards,

-- 
Benoît Minisini

2009/11/30 Benoît Minisini <gambas@...>:
>> G'day,
>>
>> I implemented a change in the gambas2 IDE. I have two questions:
>>
>> 1) Do you want it?
>> 2) If so, how do I get it to you?
>>
>> The tab implements the X11 colour names. Duplicate colour values have
>> been removed.
>>
>
> Wouldn't it better to implement such a thing into the gb.form ColorChooser
> control directly?

HA! I was hoping you'd say that.

> It is more difficult, as you must find a GUI that is not too
> disturbing. But all programs choosing color will benefit from this -

That was my thought too.

> Even if personnaly,
> I've never used X11 colour names in my entire life. :-)

I use X11 colour names in the format presented by the pngs I attached
because, to me, the whole structure is artistic, attractive, and
provides a better view of what to expect from various colour choices.
X11 names offer a much nicer user experience, IMO.

Between you and me, don't tell anyone, please, I'm all for the best
possible user experience.

> And, more important, you should better develop on Gambas 3 than Gambas 2. I
> mean, I won't merge a change in Gambas 2 if I don't have the equivalent for
> Gambas 3.

> If you agree, tell me, I will grant you a write access to the svn repository.

I gave g3 away because it seemed too unstable for what I want to achieve.

However that said, I'll look at pulling in the g3 source and seeing
what I can do with gb.form for both versions. At this stage, I will
decline the offer of write access to svn on the grounds that I want to
establish a genuine trust first. I would be pleased if you offer me
write access based on my efforts, not just on the agreements I can
make.

Besides that, being new to Linux, I'll have to check what review and
reversion options you have at your disposal if I mess something up. I
also noticed a bug in the current IDE colour chooser so I'll take a
look at that at the same time.

On a different note, I do speak a little French too. Je suis une
grande cochon! Merde! Je peut!

Of course, I don't know what the heck I just said about you, but I
think Je should be Il.

:)

Benoît Minisini wrote:

> And, more important, you should better develop on Gambas 3 than
> Gambas 2. I mean, I won't merge a change in Gambas 2 if I don't have
> the equivalent for Gambas 3.

About that. Would you accept a change for G3 without it being done for G2 
also?

> In a more general way, the order of arguments is:
> 
> - Mandatory arguments of the final constructor.
> - Mandatory arguments of the parent constructor.
> - Mandatory arguments of the grand-parent constructor.
> ... and so on.
> - Optional arguments of the final constructor.
> - Optional arguments of the parent constructor.
> - Optional arguments of the grand-parent constructor.
> ... and so on.
> 

NO, I was wrong. The order of argument is, for a three level inheritance tree:

* Mandatory arguments of the grand-parent constructor.
* Mandatory arguments of the parent constructor.
* Mandatory arguments of the final constructor.
* Optional arguments of the grand-parent constructor.
* Optional arguments of the parent constructor.
* Optional arguments of the final constructor. 

The elder classes first!

-- 
Benoît Minisini

Benoît Minisini wrote:

> There is a change in the Gambas object model in the last revision,
> about arguments passed to inherited constructors.
>
> Let's suppose that you have the following inheritance tree:
>
> A --> B --> C
>
> When instanciating C,

Your English is excellent but the correct spelling of 'instanciating" is
actually "instantiating" :)

I made a mental note to fiks that in the documentation.

(If your English is as good as know it is, you'll get the joke about fiks.)

> the constructor of A (its _new method) is
> automatically called, then the constructor of B, and finally the
> constructor of C.
>
> If constructors have arguments, they must be passed to the NEW
> instruction.
>
> Before the last change, the arguments had to be sent in reverse order:
>
> New C(Arguments for C._new, Arguments for B._new, Arguments for
> A._new)
>
> Now, they have to be sent in normal order:
>
> New C(Arguments for A._new, Arguments for B._new, Arguments for
> C._new)
>
> They are three consequences:
>
> 1) You can now have optional arguments in the C constructor.
>
> 2) Optional arguments in inherited constructors become mandatory.
> Note that only the initial constructor could have optional argument
> before, which I found finally illogical.
>
> 3) You must check your code! For example, if you created a form whose
> constructor has a string arguments, you had to do that before:

The difference between that and this is another thing I have made a note of
to ficks in the doco :)

> MyForm = New MyForm(StringArgument)
>
> And now you must do:
>
> MyForm = New MyForm(Null, StringArgument)
>
> 'Null' is actually the argument of the Window constructor, which is
> the parent of the Window.
>
> Moreover, with that change, I may be able to fix the constructor
> signature that didn't take inheritance into account until now.

Ok, serious questions....

Is there anything at all that the programmer could pass in place of Null?

If there is, what is it about that formerly Null parameter that
distinguishes it from StringArgument? In other words, is there anything that
will enable your code make a decision that "StringArgument" on its own
really means "Null, StringArgument"? If there is, why force the programmer
to pass a null if that null is unnecessary?

That is, does it make sense for a programmer to be forced to pass Null if
there are codeable rules that can decide what "StringArgument" actually
means in the absence of the Null in "Null, StringArgument"?

If that series of questions doesn't make any sense then I promise to crack
open fewer beers tomorrow.

As an example, assume A --> B --> C

If A can't deal with the parameters, then A passes them onto B.  If B can't
deal with the parameters, then B passes them onto C.

If C can't deal with the parameters, then C says to B, "Yer wot?" And B says
says to A, "Yer wot?"

A asks the programmer, "Yer wot?"

Of course, all of that makes absolutely no sense to me after an hour or more
of trying to get it to make sense, and having polished off a dozen or more
Aussie beers inbetween, I'm in no sit ftate to get it to make sense.

What I'm asking here is probably two-fold:

1) Can you make it easier for the programmer by making code-based decisions
without the need to pass nulls?

2) If so, why not make code-based decisions about what the parameters mean?

That is, essentailly, what the .NET Overrides statement does; It says, "I
can't deal with these parameters, perhaps you can?"

> Benoît Minisini wrote:
> > There is a change in the Gambas object model in the last revision,
> > about arguments passed to inherited constructors.
> >
> > Let's suppose that you have the following inheritance tree:
> >
> > A --> B --> C
> >
> > When instanciating C,
> 
> Your English is excellent but the correct spelling of 'instanciating" is
> actually "instantiating" :)

My English is not very good: I have a good dictionnary. You never hear me 
trying to speak english.

> 
> I made a mental note to fiks that in the documentation.
> 
> (If your English is as good as know it is, you'll get the joke about fiks.)
> 
> > the constructor of A (its _new method) is
> > automatically called, then the constructor of B, and finally the
> > constructor of C.
> >
> > If constructors have arguments, they must be passed to the NEW
> > instruction.
> >
> > Before the last change, the arguments had to be sent in reverse order:
> >
> > New C(Arguments for C._new, Arguments for B._new, Arguments for
> > A._new)
> >
> > Now, they have to be sent in normal order:
> >
> > New C(Arguments for A._new, Arguments for B._new, Arguments for
> > C._new)
> >
> > They are three consequences:
> >
> > 1) You can now have optional arguments in the C constructor.
> >
> > 2) Optional arguments in inherited constructors become mandatory.
> > Note that only the initial constructor could have optional argument
> > before, which I found finally illogical.
> >
> > 3) You must check your code! For example, if you created a form whose
> > constructor has a string arguments, you had to do that before:
> 
> The difference between that and this is another thing I have made a note of
> to ficks in the doco :)
> 
> > MyForm = New MyForm(StringArgument)
> >
> > And now you must do:
> >
> > MyForm = New MyForm(Null, StringArgument)
> >
> > 'Null' is actually the argument of the Window constructor, which is
> > the parent of the Window.
> >
> > Moreover, with that change, I may be able to fix the constructor
> > signature that didn't take inheritance into account until now.
> 
> Ok, serious questions....
> 
> Is there anything at all that the programmer could pass in place of Null?
> 
> If there is, what is it about that formerly Null parameter that
> distinguishes it from StringArgument? In other words, is there anything
>  that will enable your code make a decision that "StringArgument" on its
>  own really means "Null, StringArgument"? If there is, why force the
>  programmer to pass a null if that null is unnecessary?
> 
> That is, does it make sense for a programmer to be forced to pass Null if
> there are codeable rules that can decide what "StringArgument" actually
> means in the absence of the Null in "Null, StringArgument"?
> 
> If that series of questions doesn't make any sense then I promise to crack
> open fewer beers tomorrow.
> 
> As an example, assume A --> B --> C
> 
> If A can't deal with the parameters, then A passes them onto B.  If B can't
> deal with the parameters, then B passes them onto C.
> 
> If C can't deal with the parameters, then C says to B, "Yer wot?" And B
>  says says to A, "Yer wot?"
> 
> A asks the programmer, "Yer wot?"
> 
> Of course, all of that makes absolutely no sense to me after an hour or
>  more of trying to get it to make sense, and having polished off a dozen or
>  more Aussie beers inbetween, I'm in no sit ftate to get it to make sense.
> 
> What I'm asking here is probably two-fold:
> 
> 1) Can you make it easier for the programmer by making code-based decisions
> without the need to pass nulls?
> 
> 2) If so, why not make code-based decisions about what the parameters mean?
> 
> That is, essentailly, what the .NET Overrides statement does; It says, "I
> can't deal with these parameters, perhaps you can?"
> 

Some remarks:

Optional arguments must be the last ones in Gambas.

A constructor cannot tell the inherited constructor "finally I won't use this 
argument, take it". Moreover, it breaks the encapsulation.

The interpreter cannot know if an optional argument will be used or not by a 
method. So, when calling inherited constructors one by one, it must assume 
that all arguments are mandatory, except for the last constructor. How could 
it know that, for example, the second argument is an optional argument of the 
first constructor, and not a mandatory argument for the second one?

Maybe doing 'New MyForm(Null, MyArgs)' is a bit "brain-fucking", but at least 
it is not ambiguous.

Regards,

-- 
Benoît Minisini

Benoît Minisini wrote:

> A constructor cannot tell the inherited constructor "finally I won't
> use this argument, take it". Moreover, it breaks the encapsulation.

Ah. I see the problem.

> Maybe doing 'New MyForm(Null, MyArgs)' is a bit "brain-fucking", but
> at least it is not ambiguous.

lol

I have this line in my app, and it used to work, but with the new commit it does not:

$hFBrowser = New FBrowser(Settings["/Browser/Width", $Width], Settings["/Browser/Height", $Height], Settings["/Browser/X", $X], Settings["/Browser/Y", $Y])

I'm missing something? Or there is new syntax?

 Regards


--
David



----- Original Message ----
From: Benoît Minisini <gambas@...>
To: mailing list for gambas developers <gambas-devel@...>
Sent: Mon, November 30, 2009 8:08:33 AM
Subject: Re: [Gambas-devel] Arguments of inherited constructors

> Benoît Minisini wrote:
> > There is a change in the Gambas object model in the last revision,
> > about arguments passed to inherited constructors.
> >
> > Let's suppose that you have the following inheritance tree:
> >
> > A --> B --> C
> >
> > When instanciating C,
> 
> Your English is excellent but the correct spelling of 'instanciating" is
> actually "instantiating" :)

My English is not very good: I have a good dictionnary. You never hear me 
trying to speak english.

> 
> I made a mental note to fiks that in the documentation.
> 
> (If your English is as good as know it is, you'll get the joke about fiks.)
> 
> > the constructor of A (its _new method) is
> > automatically called, then the constructor of B, and finally the
> > constructor of C.
> >
> > If constructors have arguments, they must be passed to the NEW
> > instruction.
> >
> > Before the last change, the arguments had to be sent in reverse order:
> >
> > New C(Arguments for C._new, Arguments for B._new, Arguments for
> > A._new)
> >
> > Now, they have to be sent in normal order:
> >
> > New C(Arguments for A._new, Arguments for B._new, Arguments for
> > C._new)
> >
> > They are three consequences:
> >
> > 1) You can now have optional arguments in the C constructor.
> >
> > 2) Optional arguments in inherited constructors become mandatory.
> > Note that only the initial constructor could have optional argument
> > before, which I found finally illogical.
> >
> > 3) You must check your code! For example, if you created a form whose
> > constructor has a string arguments, you had to do that before:
> 
> The difference between that and this is another thing I have made a note of
> to ficks in the doco :)
> 
> > MyForm = New MyForm(StringArgument)
> >
> > And now you must do:
> >
> > MyForm = New MyForm(Null, StringArgument)
> >
> > 'Null' is actually the argument of the Window constructor, which is
> > the parent of the Window.
> >
> > Moreover, with that change, I may be able to fix the constructor
> > signature that didn't take inheritance into account until now.
> 
> Ok, serious questions....
> 
> Is there anything at all that the programmer could pass in place of Null?
> 
> If there is, what is it about that formerly Null parameter that
> distinguishes it from StringArgument? In other words, is there anything
>  that will enable your code make a decision that "StringArgument" on its
>  own really means "Null, StringArgument"? If there is, why force the
>  programmer to pass a null if that null is unnecessary?
> 
> That is, does it make sense for a programmer to be forced to pass Null if
> there are codeable rules that can decide what "StringArgument" actually
> means in the absence of the Null in "Null, StringArgument"?
> 
> If that series of questions doesn't make any sense then I promise to crack
> open fewer beers tomorrow.
> 
> As an example, assume A --> B --> C
> 
> If A can't deal with the parameters, then A passes them onto B.  If B can't
> deal with the parameters, then B passes them onto C.
> 
> If C can't deal with the parameters, then C says to B, "Yer wot?" And B
>  says says to A, "Yer wot?"
> 
> A asks the programmer, "Yer wot?"
> 
> Of course, all of that makes absolutely no sense to me after an hour or
>  more of trying to get it to make sense, and having polished off a dozen or
>  more Aussie beers inbetween, I'm in no sit ftate to get it to make sense.
> 
> What I'm asking here is probably two-fold:
> 
> 1) Can you make it easier for the programmer by making code-based decisions
> without the need to pass nulls?
> 
> 2) If so, why not make code-based decisions about what the parameters mean?
> 
> That is, essentailly, what the .NET Overrides statement does; It says, "I
> can't deal with these parameters, perhaps you can?"
> 

Some remarks:

Optional arguments must be the last ones in Gambas.

A constructor cannot tell the inherited constructor "finally I won't use this 
argument, take it". Moreover, it breaks the encapsulation.

The interpreter cannot know if an optional argument will be used or not by a 
method. So, when calling inherited constructors one by one, it must assume 
that all arguments are mandatory, except for the last constructor. How could 
it know that, for example, the second argument is an optional argument of the 
first constructor, and not a mandatory argument for the second one?

Maybe doing 'New MyForm(Null, MyArgs)' is a bit "brain-fucking", but at least 
it is not ambiguous.

Regards,

-- 
Benoît Minisini

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gambas-devel mailing list
Gambas-devel@...
https://lists.sourceforge.net/lists/listinfo/gambas-devel

> I have this line in my app, and it used to work, but with the new commit it
>  does not:
> 
> $hFBrowser = New FBrowser(Settings["/Browser/Width", $Width],
>  Settings["/Browser/Height", $Height], Settings["/Browser/X", $X],
>  Settings["/Browser/Y", $Y])
> 
> I'm missing something? Or there is new syntax?
> 
>  Regards
> 
> 
> --
> David
> 

You must now pass the optional argument of the Window constructor first:

$hFBrowser = New FBrowser(Null, Settings["/Browser/Width", $Width],
 Settings["/Browser/Height", $Height], Settings["/Browser/X", $X],
 Settings["/Browser/Y", $Y])

Regards,

-- 
Benoît Minisini

> Hi, here is the "new" version of the control. Please let me know any
>  comment.
> 
>  Regards
> 
> 
> --
> David
> 

Ane here are my comments:

- The Format property constants should be 0 and 1.

- If you can only enter an hour between 0 and 11, you should be able to enter 
AM/PM too somewhere.

- The border must be optional, by making a Border property. You can decide if 
you want a boolean Border property, or an integer one taking one of the 
constants of the Border class.

- When a SpinBox gets focus, maybe it would be better to select all its text.

- You must not set the font of the spinboxes. It must be the font of the 
control.

I will implement a SpinBox.Border property to be able to not display its 
border, like TextBox.

Regards,

-- 
Benoît Minisini

On Wednesday 25 November 2009 13:45:07 Benoît Minisini wrote:
> The support has landed in the revision 2438.
> 
> It was not that simple, and at the moment there is a workaround in the IDE
> because the DB.Quote() function cannot handle them.
> 
> Allowing DB.Quote() to correctly quote table names with a schema name
>  inside needs a little change in the database driver interface, so I will
>  do that later. Maybe with the DB.QuoteBlob() function.
> 
> Regards,
> 
Thanks Benoit as always I'm impressed.

Regards

Richard

> The support has landed in the revision 2438.
> 
> It was not that simple, and at the moment there is a workaround in the IDE
> because the DB.Quote() function cannot handle them.
> 
> Allowing DB.Quote() to correctly quote table names with a schema name
>  inside needs a little change in the database driver interface, so I will
>  do that later. Maybe with the DB.QuoteBlob() function.
> 
> Regards,
> 

In revision #2442, the support for postgresql schema is now far better. 

Moreover, I added a FormatBlob() function to the Connection class to get the 
SQL string representation of binary data that you should use inside a blob.

It's up to Richard and Jean-Yves to tell me if all that work as expected.

Note: this is for Gambas 3 only, because of the changes in the interface.

Regards,

-- 
Benoît Minisini

Hey ,friend  I find a site to sell electronic products with very good price. Laptop ,iPhone even Motorcycle are very popular .their products are original quality with very low price as wholesale business supplier.They also can do retail business for end user now. maybe it is fit for your business . if you like you can contact them :   wholesalers-electronic.com  <br>E-mail:  wholesaler318(at)188.com<br>Msn : wholesaler31888(at)hotmail.com<br>

> Hi Benoit, I got a MAC-Intel, if you want I can open a ssh connection for
>  you to make some test. 

Yes it could be useful!

With Mac/Intel, there is no endianness problem anymore. And the Unix part is 
based on FreeBSD, where Gambas compiles as far as I know. There is just a 
recent problem on FreeBSD (with the Round() function), but I have not enough 
information to understand what happens. Maybe I will see the same problem on 
Mac and will be able to fix it.

The big problem is: I have no idea how GUI component will run.

- How Qt and GTK+ work on Mac-OSX?

- The gambas GUI components use many X11 specific stuff. Is there some sort of 
X11 emulation on Mac-OSX?

If you have some answer about that, i.e. you can successfully compile the 
Gambas sources on Mac (which will mean that X11 libraries are present, and 
that Qt or GTK+ have no problem with Mac OSX), it will be a huge step!

>  I think in some time I will have aviable a MAC for
>  you to make more test.

What do you mean exactly?

-- 
Benoît Minisini

I mean a MAC/Power PC not a MAC/Intel. And really I don't know if there is X11 in MAC.

I'll send you the IP, User & Pass soon, to your personal account, of course. :)

 Regards


--
David



----- Original Message ----
From: Benoît Minisini <gambas@...>
To: mailing list for gambas developers <gambas-devel@...>
Sent: Thu, November 26, 2009 4:09:50 PM
Subject: Re: [Gambas-devel] Gambas on MAC

> Hi Benoit, I got a MAC-Intel, if you want I can open a ssh connection for
>  you to make some test. 

Yes it could be useful!

With Mac/Intel, there is no endianness problem anymore. And the Unix part is 
based on FreeBSD, where Gambas compiles as far as I know. There is just a 
recent problem on FreeBSD (with the Round() function), but I have not enough 
information to understand what happens. Maybe I will see the same problem on 
Mac and will be able to fix it.

The big problem is: I have no idea how GUI component will run.

- How Qt and GTK+ work on Mac-OSX?

- The gambas GUI components use many X11 specific stuff. Is there some sort of 
X11 emulation on Mac-OSX?

If you have some answer about that, i.e. you can successfully compile the 
Gambas sources on Mac (which will mean that X11 libraries are present, and 
that Qt or GTK+ have no problem with Mac OSX), it will be a huge step!

>  I think in some time I will have aviable a MAC for
>  you to make more test.

What do you mean exactly?

-- 
Benoît Minisini

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gambas-devel mailing list
Gambas-devel@...
https://lists.sourceforge.net/lists/listinfo/gambas-devel

> It's not the question the are equal or not.
> Its looks to be the problem the object in the collection is distroyed.
> Again, that is how I understand Richards problem !!!.
> 
> Sometimes it can be nice to remove empty but it's logical IMHO.
> 

OK, I see. You can use the destination Record to get the field list, like 
that:

	Dim hField As ResultField

	For Each hField in MyResult.Fields
	  MyResult[hField.Name] = MyCollection[hField.Name]
	Next

Regards,

-- 
Benoît Minisini