From david.villalobos.c at ...176...  Thu Apr  8 17:46:50 2010
From: david.villalobos.c at ...176... (David Villalobos Cambronero)
Date: Thu, 8 Apr 2010 09:46:50 -0600
Subject: [Gambas-devel] Event CloseWindow in WorkSpace
Message-ID: <g2hc42ff1b51004080846u94f75d79kc82d257218814219@...178...>

Hi, it will be difficult to add a CloseWindow event to the WorkSpace? I need
to know when the current window is closed, so I can validate some thing?

Or there is already a way yo do it?

-- 
Regards
---
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20100408/773b354a/attachment.html>

From gambas at ...1...  Thu Apr  8 18:25:45 2010
From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=)
Date: Thu, 8 Apr 2010 18:25:45 +0200
Subject: [Gambas-devel] Event CloseWindow in WorkSpace
In-Reply-To: <g2hc42ff1b51004080846u94f75d79kc82d257218814219@...178...>
References: <g2hc42ff1b51004080846u94f75d79kc82d257218814219@...178...>
Message-ID: <201004081825.45980.gambas@...1...>

> Hi, it will be difficult to add a CloseWindow event to the WorkSpace? I
> need to know when the current window is closed, so I can validate some
> thing?
> 
> Or there is already a way yo do it?

Maybe. But why don't you use the Form close event ?

-- 
Beno?t Minisini



From david.villalobos.c at ...176...  Thu Apr  8 18:38:09 2010
From: david.villalobos.c at ...176... (David Villalobos Cambronero)
Date: Thu, 8 Apr 2010 10:38:09 -0600
Subject: [Gambas-devel] Event CloseWindow in WorkSpace
In-Reply-To: <201004081825.45980.gambas@...1...>
References: <g2hc42ff1b51004080846u94f75d79kc82d257218814219@...178...> 
	<201004081825.45980.gambas@...1...>
Message-ID: <k2zc42ff1b51004080938le6a1a850p742ec949661d6ceb@...178...>

2010/4/8 Beno?t Minisini <gambas at ...1...>

> > Hi, it will be difficult to add a CloseWindow event to the WorkSpace? I
> > need to know when the current window is closed, so I can validate some
> > thing?
> >
> > Or there is already a way yo do it?
>
> Maybe. But why don't you use the Form close event ?
>
> --
> Beno?t Minisini
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>

It could, but I'm adding a Class that inherits from Window.

Maybe the problem is my programing skills :)

In this example:

---------------------------------------------------
' Gambas class file

Inherits Window

Public Sub _new()

  Me.Arrangement = Arrange.Fill

End
---------------------------------------------------

How do I implment the Close() event?
-- 
Gracias
---
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20100408/6016c2c5/attachment.html>

From gambas at ...1...  Thu Apr  8 18:43:44 2010
From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=)
Date: Thu, 8 Apr 2010 18:43:44 +0200
Subject: [Gambas-devel] Event CloseWindow in WorkSpace
In-Reply-To: <k2zc42ff1b51004080938le6a1a850p742ec949661d6ceb@...178...>
References: <g2hc42ff1b51004080846u94f75d79kc82d257218814219@...178...>
	<201004081825.45980.gambas@...1...>
	<k2zc42ff1b51004080938le6a1a850p742ec949661d6ceb@...178...>
Message-ID: <201004081843.44587.gambas@...1...>

> 2010/4/8 Beno?t Minisini <gambas at ...1...>
> 
> > > Hi, it will be difficult to add a CloseWindow event to the WorkSpace? I
> > > need to know when the current window is closed, so I can validate some
> > > thing?
> > > 
> > > Or there is already a way yo do it?
> > 
> > Maybe. But why don't you use the Form close event ?
> > 
> > --
> > Beno?t Minisini
> > 
> > 
> > -------------------------------------------------------------------------
> > ----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Gambas-devel mailing list
> > Gambas-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gambas-devel
> 
> It could, but I'm adding a Class that inherits from Window.
> 
> Maybe the problem is my programing skills :)
> 
> In this example:
> 
> ---------------------------------------------------
> ' Gambas class file
> 
> Inherits Window
> 
> Public Sub _new()
> 
>   Me.Arrangement = Arrange.Fill
> 
> End
> ---------------------------------------------------
> 
> How do I implment the Close() event?

The Close event is received by the main observer of your window, normally the 
object where you created the window.

-- 
Beno?t Minisini



From david.villalobos.c at ...176...  Thu Apr  8 18:48:54 2010
From: david.villalobos.c at ...176... (David Villalobos Cambronero)
Date: Thu, 8 Apr 2010 10:48:54 -0600
Subject: [Gambas-devel] Event CloseWindow in WorkSpace
In-Reply-To: <201004081843.44587.gambas@...1...>
References: <g2hc42ff1b51004080846u94f75d79kc82d257218814219@...178...> 
	<201004081825.45980.gambas@...1...>
	<k2zc42ff1b51004080938le6a1a850p742ec949661d6ceb@...178...>
	<201004081843.44587.gambas@...1...>
Message-ID: <r2kc42ff1b51004080948k9626f2e4h72152460b5e816da@...178...>

2010/4/8 Beno?t Minisini <gambas at ...1...>

> > 2010/4/8 Beno?t Minisini <gambas at ...1...>
> >
> > > > Hi, it will be difficult to add a CloseWindow event to the WorkSpace?
> I
> > > > need to know when the current window is closed, so I can validate
> some
> > > > thing?
> > > >
> > > > Or there is already a way yo do it?
> > >
> > > Maybe. But why don't you use the Form close event ?
> > >
> > > --
> > > Beno?t Minisini
> > >
> > >
> > >
> -------------------------------------------------------------------------
> > > ----- Download Intel&#174; Parallel Studio Eval
> > > Try the new software tools for yourself. Speed compiling, find bugs
> > > proactively, and fine-tune applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > Gambas-devel mailing list
> > > Gambas-devel at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/gambas-devel
> >
> > It could, but I'm adding a Class that inherits from Window.
> >
> > Maybe the problem is my programing skills :)
> >
> > In this example:
> >
> > ---------------------------------------------------
> > ' Gambas class file
> >
> > Inherits Window
> >
> > Public Sub _new()
> >
> >   Me.Arrangement = Arrange.Fill
> >
> > End
> > ---------------------------------------------------
> >
> > How do I implment the Close() event?
>
> The Close event is received by the main observer of your window, normally
> the
> object where you created the window.
>
> --
> Beno?t Minisini
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>

Sure it will, it solve the issue, feel so stupid asking this!!! maybe I'm
working a lot

-- 
Regards
---
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20100408/9f37d54c/attachment.html>

From nospam.nospam.nospam at ...176...  Fri Apr  9 05:51:21 2010
From: nospam.nospam.nospam at ...176... (Kad Mann)
Date: Fri, 9 Apr 2010 13:51:21 +1000
Subject: [Gambas-devel] Event CloseWindow in WorkSpace
References: <g2hc42ff1b51004080846u94f75d79kc82d257218814219@...178...>
	<201004081825.45980.gambas@...1...><k2zc42ff1b51004080938le6a1a850p742ec949661d6ceb@...178...><201004081843.44587.gambas@...1...>
	<r2kc42ff1b51004080948k9626f2e4h72152460b5e816da@...178...>
Message-ID: <9B139FB6E136486886F56AA9BAD33D28@...645...>

David Villalobos Cambronero wrote:

> I feel so stupid asking this!!!

Don't feel that way. Sometimes the obvious is not obvious.



From david.villalobos.c at ...176...  Fri Apr  9 15:40:37 2010
From: david.villalobos.c at ...176... (David Villalobos Cambronero)
Date: Fri, 9 Apr 2010 07:40:37 -0600
Subject: [Gambas-devel] Event CloseWindow in WorkSpace
In-Reply-To: <9B139FB6E136486886F56AA9BAD33D28@...645...>
References: <g2hc42ff1b51004080846u94f75d79kc82d257218814219@...178...> 
	<201004081825.45980.gambas@...1...>
	<k2zc42ff1b51004080938le6a1a850p742ec949661d6ceb@...178...>
	<201004081843.44587.gambas@...1...>
	<r2kc42ff1b51004080948k9626f2e4h72152460b5e816da@...178...>
	<9B139FB6E136486886F56AA9BAD33D28@...645...>
Message-ID: <i2ic42ff1b51004090640n1a8dfab0r796cd38fbbf9d4d7@...178...>

On Thu, Apr 8, 2010 at 9:51 PM, Kad Mann <nospam.nospam.nospam at ...176...>wrote:

> David Villalobos Cambronero wrote:
>
> > I feel so stupid asking this!!!
>
> Don't feel that way. Sometimes the obvious is not obvious.
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>

Thanks!! :)

-- 
Gracias
---
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20100409/b3fbaadd/attachment.html>

From gambas at ...1...  Sat Apr 17 14:20:30 2010
From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=)
Date: Sat, 17 Apr 2010 14:20:30 +0200
Subject: [Gambas-devel] Short-Circuit and Key.Text
In-Reply-To: <u2ld0f8bc231004161944w26fc2eefw468e3947b8345955@...178...>
References: <o2kd0f8bc231004161532tc2d20dc1u620219ef889bbeee@...178...>
	<201004170041.31026.gambas@...1...>
	<u2ld0f8bc231004161944w26fc2eefw468e3947b8345955@...178...>
Message-ID: <201004171420.30567.gambas@...1...>

> 2010/4/16 Beno?t Minisini <gambas at ...1...>:
> > You should not implement a DateBox that will just manage a date. You must
> > implement a ValueBox control that does at least the same thing that the
> > old one, because it is used in other components. But maybe this is your
> > plan?
> 
> Just is a design test. The final goal is write a ValueBox control.

OK, cool.

Actually is it a good idea. We should provide some specific controls to edit 
specific datatypes, and merge them inside the ValueBox:

- Your DateBox, that may replace DatePicker.
- a "MaskBox", that would be a TextBox with a mask. It could be use to edit 
things like "IP address", "emails"... I will work on that, to see if a new 
control is needed, or if TextBox can get the mask directly.

> 
> Someone else is working on that? I wonder you because I installed
> Gambas3 and I saw changes in the sources of ValueBox. I don't want
> duplicate efforts.

Some changes were made only in Gambas 3 because Gambas 2 can only get bug 
fixes, not new features. But you must work on Gambas 3. So, ignore the 
changes, or take them. Do as you like! :-)

In a few words, the goal of ValueBox is being able to edit a value according 
to its datatype and/or its meaning.

The datatype and the meaning is not necessarily the same thing. For example, a 
"String" and a "IP address" should not be edited the same way, but a "Date" is 
just a date.

The value editor should adapt to the datatype: a (working) popup calendar for 
a date, a spinbox for a integer number within a range...

The ValueBox.Type property can be an integer like now, or a string that 
describes the ValueBox meaning entirely.

Let's suppose we take the last way, which is more open to the future. :-)

The ValueBox.Type could be :

Integer[:Format]
Number[:Format]
Range[:Min:Max]
Date
Time
IPAddress
MailAddress
Color
Boolean
File
URL
Currency
Font
...

We could take a syntax that ":" is a separator, and that everything between 
":" is a type argument.

According to the type, the ValueBox will use a TextBox, a SpinBox, a DateBox, 
a ButtonBox whose button will open a specific editor... And so on.

What do you think about that?

P.S. We should talk on the developer mailing-list so that everything is 
archived and visible to other interested people.

Regards,

-- 
Beno?t Minisini



From fabianfloresvadell at ...176...  Sat Apr 17 20:36:40 2010
From: fabianfloresvadell at ...176... (=?ISO-8859-1?Q?Fabi=E1n_Flores_Vadell?=)
Date: Sat, 17 Apr 2010 15:36:40 -0300
Subject: [Gambas-devel] ValueBox
Message-ID: <p2nd0f8bc231004171136qef6c9f82g4398daa2d11e40ec@...178...>

>> Just is a design test. The final goal is write a ValueBox control.

>OK, cool.
>
>Actually is it a good idea. We should provide some specific controls to edit
>specific datatypes, and merge them inside the ValueBox:
>
>- Your DateBox, that may replace DatePicker.

I think that they should be merge.

>- a "MaskBox", that would be a TextBox with a mask. It could be use to edit
>things like "IP address", "emails"... I will work on that, to see if a new
>control is needed, or if TextBox can get the mask directly.

So, If you are thinking in two alternatives, seems to me that they are
TextBox and ValueBox.

But I believe that there should be improved TextBox's current
functionality and to rewrite ValueBox to improve it and to add
functionality also.

In TextBox:

- As in that example I sent you before, allow the use of String class
associated to Text property, assuming than Text is the default
property. Example: TextBox1.UCase, TextBox1.Mid(Pos, Length) - the
String argument would be innecesary.

This can seem something unhelpful, but could avoid than Gambas users
faces the desicion about use Len(TextBox1.Text) or
String.Len(TextBox1.Text). Moreover, write less code would also
allowed.

- Add search capabilities. Example: TextBox1.Text.Find(Pattern),
TextBox1.Text.FindNext(Pattern)

- Add the possibility to have a label associated to TextBox (by a
property named labeled?) so it can be located to the left or above
TextBox, depending on the user taste.

- Add in TextBox a boolean property to allow manage the
obligatoriness. Then, if the user set a named Mandatory property in a
TextBox control, Gambas should create automatically a collection with
the mandatories TextBox (or other mandatory controls too). So, the
user can set the Mandatory property and then iterates through the
collection to verify its controls.

Mask could be a static class in Gambas, so it could be used in
TextBox, ValueBox, etc. So, MaskBox could be a specialized class from
ValueBox.

>In a few words, the goal of ValueBox is being able to edit a value according
>to its datatype and/or its meaning.
>
>The datatype and the meaning is not necessarily the same thing. For example, a
>"String" and a "IP address" should not be edited the same way, but a "Date" is
>just a date.
>
>The value editor should adapt to the datatype: a (working) popup calendar for
>a date, a spinbox for a integer number within a range...
>
>The ValueBox.Type property can be an integer like now, or a string that
>describes the ValueBox meaning entirely.
>
>Let's suppose we take the last way, which is more open to the future. :-)
>
>The ValueBox.Type could be :
>
>Integer[:Format]
>Number[:Format]
>Range[:Min:Max]
>Date
>Time
>IPAddress
>MailAddress
>Color
>Boolean
>File
>URL
>Currency
>Font
>.
>
>We could take a syntax that ":" is a separator, and that everything between
>":" is a type argument.
>
>According to the type, the ValueBox will use a TextBox, a SpinBox, a DateBox,
>a ButtonBox whose button will open a specific editor... And so on.
>
>What do you think about that?

Is exactly what I infer from my test design.

I was thinking in create a base (virtual) class with the common
functionality and derived classes with a specific behavior. When the
user define a Type for ValueBox, internally a specialized class is
instantiated.

I wrote DateBox like a aggregation of 3 TextBox (Day-Month-Year). This
had simplified the encoding a little, but perhaps the result is not
very aesthetic.

However, if I generalize this class, I can write derived classes for
manage time (TimeBox, 3 TextBox for HH, MM  and SS) and IP (IPBox, 4
TextBox), at least.

Then, I refactor my code so the names have a more abstract mean
(without symbols than refers to date, day, month or year) and other
changes in order to achieve that goal. Thus I could evaluate a bit the
risk about the implementation. But I not finished yet.

So, independently of implementation,  I think that this could be the
design criteria. But, I see a problem here, Gambas just provides one
level of inheritance. So, ValueBox can't inherit from UserControl or
UserContainer, or the design criteria should be other.

Well I hope  you like my proposed changes and my ideas, but if not,
feel free to let me know (and please explain to me why)


Regards.

--
Fabi?n Flores Vadell
www.speedbooksargentina.blogspot.com



From gambas at ...1...  Sun Apr 18 00:40:36 2010
From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=)
Date: Sun, 18 Apr 2010 00:40:36 +0200
Subject: [Gambas-devel] ValueBox
In-Reply-To: <p2nd0f8bc231004171136qef6c9f82g4398daa2d11e40ec@...178...>
References: <p2nd0f8bc231004171136qef6c9f82g4398daa2d11e40ec@...178...>
Message-ID: <201004180040.36370.gambas@...1...>

> >> Just is a design test. The final goal is write a ValueBox control.
> >
> >OK, cool.
> >
> >Actually is it a good idea. We should provide some specific controls to
> >edit specific datatypes, and merge them inside the ValueBox:
> >
> >- Your DateBox, that may replace DatePicker.
> 
> I think that they should be merge.
> 
> >- a "MaskBox", that would be a TextBox with a mask. It could be use to
> >edit things like "IP address", "emails"... I will work on that, to see if
> >a new control is needed, or if TextBox can get the mask directly.
> 
> So, If you are thinking in two alternatives, seems to me that they are
> TextBox and ValueBox.
> 
> But I believe that there should be improved TextBox's current
> functionality and to rewrite ValueBox to improve it and to add
> functionality also.
> 
> In TextBox:
> 
> - As in that example I sent you before, allow the use of String class
> associated to Text property, assuming than Text is the default
> property. Example: TextBox1.UCase, TextBox1.Mid(Pos, Length) - the
> String argument would be innecesary.
> 
> This can seem something unhelpful, but could avoid than Gambas users
> faces the desicion about use Len(TextBox1.Text) or
> String.Len(TextBox1.Text). Moreover, write less code would also
> allowed.
> 
> - Add search capabilities. Example: TextBox1.Text.Find(Pattern),
> TextBox1.Text.FindNext(Pattern)
> 
> - Add the possibility to have a label associated to TextBox (by a
> property named labeled?) so it can be located to the left or above
> TextBox, depending on the user taste.
> 
> - Add in TextBox a boolean property to allow manage the
> obligatoriness. Then, if the user set a named Mandatory property in a
> TextBox control, Gambas should create automatically a collection with
> the mandatories TextBox (or other mandatory controls too). So, the
> user can set the Mandatory property and then iterates through the
> collection to verify its controls.

I won't do the previous methods, because TextBox is a native control in both 
gb.qt and gb.gtk, and so its methods must be native methods. 

All that is syntactic sugar that can be implemented by extending the TextBox 
directly in Gambas code.

There is no problem with knowing if Len() or String.Len() should be use. Len() 
returns the string length in bytes, String.Len() the number of UTF-8 
characters. 

TextBox.Length = String.Len(TextBox.Text), it is just a lot faster. 

A TextBox.Mid() function would be a little faster then String.Mid() applied on 
TextBox.Text, but marginally as the length of a TextBox string is usually low, 
and if you implement TextBox.Mid(), you will logically have to implement all 
the other methods of the String class!

Generally, if I can avoid implementing an interface (i.e. a method or a 
property), because the same feature can be implemented without too much 
penalty, or because implementing it lead to too many disadvantages, I don't 
implement it.

Too much design is as bad as too few design!

> 
> Mask could be a static class in Gambas, so it could be used in
> TextBox, ValueBox, etc. So, MaskBox could be a specialized class from
> ValueBox.
> 

I don't see the need of the mask property outside of the TextBox or MaskedBox 
control, because it implies both formatting the displayed text and managing 
the key events.

> >In a few words, the goal of ValueBox is being able to edit a value
> >according to its datatype and/or its meaning.
> >
> >The datatype and the meaning is not necessarily the same thing. For
> >example, a "String" and a "IP address" should not be edited the same way,
> >but a "Date" is just a date.
> >
> >The value editor should adapt to the datatype: a (working) popup calendar
> >for a date, a spinbox for a integer number within a range...
> >
> >The ValueBox.Type property can be an integer like now, or a string that
> >describes the ValueBox meaning entirely.
> >
> >Let's suppose we take the last way, which is more open to the future. :-)
> >
> >The ValueBox.Type could be :
> >
> >Integer[:Format]
> >Number[:Format]
> >Range[:Min:Max]
> >Date
> >Time
> >IPAddress
> >MailAddress
> >Color
> >Boolean
> >File
> >URL
> >Currency
> >Font
> >.
> >
> >We could take a syntax that ":" is a separator, and that everything
> >between ":" is a type argument.
> >
> >According to the type, the ValueBox will use a TextBox, a SpinBox, a
> >DateBox, a ButtonBox whose button will open a specific editor... And so
> >on.
> >
> >What do you think about that?
> 
> Is exactly what I infer from my test design.
> 
> I was thinking in create a base (virtual) class with the common
> functionality and derived classes with a specific behavior. When the
> user define a Type for ValueBox, internally a specialized class is
> instantiated.
> 
> I wrote DateBox like a aggregation of 3 TextBox (Day-Month-Year). This
> had simplified the encoding a little, but perhaps the result is not
> very aesthetic.
> 
> However, if I generalize this class, I can write derived classes for
> manage time (TimeBox, 3 TextBox for HH, MM  and SS) and IP (IPBox, 4
> TextBox), at least.
> 

Don't forget that the user may want to edit just a date, just a time, or both 
date and time. The same DateBox control should allow all that. And have a 
popup calendar for the date part.

> Then, I refactor my code so the names have a more abstract mean
> (without symbols than refers to date, day, month or year) and other
> changes in order to achieve that goal. Thus I could evaluate a bit the
> risk about the implementation. But I not finished yet.
> 
> So, independently of implementation,  I think that this could be the
> design criteria. But, I see a problem here, Gambas just provides one
> level of inheritance. So, ValueBox can't inherit from UserControl or
> UserContainer, or the design criteria should be other.
> 
> Well I hope  you like my proposed changes and my ideas, but if not,
> feel free to let me know (and please explain to me why)

I'm not sure if using inheritance for implementing all the possible features 
of ValueBox is a good idea. I'm not against DateBox, but I don't like having 
dozen of different controls for editing different things.

I prefer an unique interface, ValueBox, whose behaviour is entirely defined by 
its Type property. Don't forget that I want to use this control in the GUI 
database component, to easily edit database fields. I want to let the user 
have an optional gambas-specific metadata table in its database, that the 
component will use to configure the ValueBox that will edit each field.

Regards,

-- 
Beno?t Minisini



From priastefano at ...506...  Mon Apr 19 23:13:08 2010
From: priastefano at ...506... (Tim Stefano)
Date: Mon, 19 Apr 2010 23:13:08 +0200
Subject: [Gambas-devel] Gambas-devel Digest, Vol 45, Issue 2
References: <mailman.234945.1271529409.8007.gambas-devel@lists.sourceforge.net>
Message-ID: <4C547863333C45108B797415726D6BC7@...650...>


Montelupo Fiorentino - Italy 19 Aprile 2010

Hi to all,

I have an answer: how can I send BACKSPACE character to Desktop.sendkeys ?

I try to do a touch screen keyboard.... but I don't know how can I send all 
the strange characters like BACKSPACE, DELETE,

I try with Desktop.sendkeys("[RETURN]") like the documentation say... but 
don't work.

Thank's for help

Distinti saluti - Best regards
            Stefano Pria 




From gambas at ...1...  Tue Apr 20 22:40:02 2010
From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=)
Date: Tue, 20 Apr 2010 22:40:02 +0200
Subject: [Gambas-devel] User components in Gambas 3
Message-ID: <201004202240.02466.gambas@...1...>

Hi,

I post this mail on both mailing-lists: please answer on the developer 
mailing-list if possible, as this is related to the development version!

I'm currently thinking about how user components should work in Gambas 3, as I 
dislike the way it was designed in Gambas 2.

In Gambas 2, user components work the same way as normal components made with 
Gambas, except that they are symbolic located in the home directory that point 
at the real executables.

That design lead to many problems: you can't make packages of user components 
easily, and if the real executable moves, the symbolic link is broken while 
the IDE think the component is there.

So, for Gambas 3, I propose a different design:

- There are no "user" components anymore.

- Instead, a project will be able to depend on other projects.

- The list of associated projects will be defined in the IDE project option 
dialog.

- That list will be just a list of project *names*.

- At design time, these project will be search inside one or more directories 
that will be defined as a IDE global option.

- At run time, the associated projects will be searched by using the $PATH 
environmental variable, as any other executables.

Consequently:

- The IDE global option will tell where you store the projects you want to use 
as components.

- These projects will be packaged separately and installed like any other 
Gambas projects.

- They should have a special name, because they are not real executables, but 
some sort of "Gambas" libraries instead.

- So the project executables should be in the $PATH. And so the main project 
will find them easily.

- When creating the main project packages, it will be easy to add a dependency 
on the associated project packages.

I need to find a good term for these "associated" projects. I'd like to find 
something different than "component". 

Even if internally the interpreter will use the same code to load them, I want 
the user to understand easily that they do not work the same way.

Maybe "library" would be a good term...

What do you think about the new design?

-- 
Beno?t Minisini



From david.villalobos.c at ...176...  Tue Apr 20 23:58:20 2010
From: david.villalobos.c at ...176... (David Villalobos Cambronero)
Date: Tue, 20 Apr 2010 15:58:20 -0600
Subject: [Gambas-devel] User components in Gambas 3
In-Reply-To: <201004202240.02466.gambas@...1...>
References: <201004202240.02466.gambas@...1...>
Message-ID: <l2lc42ff1b51004201458v53604457je14d5c7b4037fc39@...178...>

2010/4/20 Beno?t Minisini <gambas at ...1...>

> Hi,
>
> I post this mail on both mailing-lists: please answer on the developer
> mailing-list if possible, as this is related to the development version!
>
> I'm currently thinking about how user components should work in Gambas 3,
> as I
> dislike the way it was designed in Gambas 2.
>
> In Gambas 2, user components work the same way as normal components made
> with
> Gambas, except that they are symbolic located in the home directory that
> point
> at the real executables.
>
> That design lead to many problems: you can't make packages of user
> components
> easily, and if the real executable moves, the symbolic link is broken while
> the IDE think the component is there.
>
> So, for Gambas 3, I propose a different design:
>
> - There are no "user" components anymore.
>
> - Instead, a project will be able to depend on other projects.
>
> - The list of associated projects will be defined in the IDE project option
> dialog.
>
> - That list will be just a list of project *names*.
>
> - At design time, these project will be search inside one or more
> directories
> that will be defined as a IDE global option.
>
> - At run time, the associated projects will be searched by using the $PATH
> environmental variable, as any other executables.
>
> Consequently:
>
> - The IDE global option will tell where you store the projects you want to
> use
> as components.
>
> - These projects will be packaged separately and installed like any other
> Gambas projects.
>
> - They should have a special name, because they are not real executables,
> but
> some sort of "Gambas" libraries instead.
>
> - So the project executables should be in the $PATH. And so the main
> project
> will find them easily.
>
> - When creating the main project packages, it will be easy to add a
> dependency
> on the associated project packages.
>
> I need to find a good term for these "associated" projects. I'd like to
> find
> something different than "component".
>
> Even if internally the interpreter will use the same code to load them, I
> want
> the user to understand easily that they do not work the same way.
>
> Maybe "library" would be a good term...
>
> What do you think about the new design?
>
> --
> Beno?t Minisini
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>

I think it is OK, see no problem.

Here are some synonyms for component, may help you find a good name: basic,
composing,  elemental, fundamental, inherent, integral, intrinsic, part
and  parcel  of,  part  of, part, element, constituent, factor, fixings,
ingredient, item, making, makings, peripheral, piece, plug-in, segment,
unit.

-- 
Regards
---
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20100420/b7440354/attachment.html>

From Karl.Reinl at ...646...  Wed Apr 21 10:53:25 2010
From: Karl.Reinl at ...646... (Charlie Reinl)
Date: Wed, 21 Apr 2010 10:53:25 +0200
Subject: [Gambas-devel] User components in Gambas 3
In-Reply-To: <201004202240.02466.gambas@...1...>
References: <201004202240.02466.gambas@...1...>
Message-ID: <1271840005.6521.24.camel@...102...>

Am Dienstag, den 20.04.2010, 22:40 +0200 schrieb Beno?t Minisini:
Salut,

I will write into your mail, to tell
> Hi,
> 
> I post this mail on both mailing-lists: please answer on the developer 
> mailing-list if possible, as this is related to the development version!
> 
> I'm currently thinking about how user components should work in Gambas 3, as I 
> dislike the way it was designed in Gambas 2.
> 
> In Gambas 2, user components work the same way as normal components made with 
> Gambas, except that they are symbolic located in the home directory that point 
> at the real executables.

> That design lead to many problems: you can't make packages of user components 
> easily, and if the real executable moves, the symbolic link is broken while 
> the IDE think the component is there.

That's only while MakeLink in the IDE isn't *perfect* 

> 
> So, for Gambas 3, I propose a different design:
> 
> - There are no "user" components anymore.
> 
> - Instead, a project will be able to depend on other projects.
> 
> - The list of associated projects will be defined in the IDE project option 
> dialog.
> 
> - That list will be just a list of project *names*.
> 
> - At design time, these project will be search inside one or more directories 
> that will be defined as a IDE global option.
> 
> - At run time, the associated projects will be searched by using the $PATH 
> environmental variable, as any other executables.
> 
> Consequently:
> 
> - The IDE global option will tell where you store the projects you want to use 
> as components.
> 
> - These projects will be packaged separately and installed like any other 
> Gambas projects.
> 
> - They should have a special name, because they are not real executables, but 
> some sort of "Gambas" libraries instead.

For me that will be a BIG problem, because, some of my "components" are
executables, which used in other projects.

Why, even if retaining all of the points below, it could not be
executable and/or library.

> - So the project executables should be in the $PATH. And so the main project 
> will find them easily.
> 
> - When creating the main project packages, it will be easy to add a dependency 
> on the associated project packages.

For packages a big step forward  

> 
> I need to find a good term for these "associated" projects. I'd like to find 
> something different than "component". 
> 
> Even if internally the interpreter will use the same code to load them, I want 
> the user to understand easily that they do not work the same way.
> 
> Maybe "library" would be a good term...

here are synonyms for component (in german) :
Abschnitt, Teil, Part, Partie, Segment, Bereich, Teilst?ck, Etape,
Periode, Etappe, Zyklus,Bauteil, Baustein, Bauelement, Modul, Element,
Bestandteil, Glied, Element, Grundstoff

That is the output of the google-translater : 

Section, part, part, section, segment, range, section, Etape, period,
phase, cycle, Component, device, component, module, element, component,
element, element, basic, 

And : "gambas-Add On", gambas-domino, gambas-link
> 
> What do you think about the new design?


-- 
Amicalement
Charlie




From gambas at ...1...  Wed Apr 21 11:30:37 2010
From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=)
Date: Wed, 21 Apr 2010 11:30:37 +0200
Subject: [Gambas-devel] User components in Gambas 3
In-Reply-To: <1271840005.6521.24.camel@...102...>
References: <201004202240.02466.gambas@...1...>
	<1271840005.6521.24.camel@...102...>
Message-ID: <201004211130.38027.gambas@...1...>

> > 
> > - They should have a special name, because they are not real executables,
> > but some sort of "Gambas" libraries instead.
> 
> For me that will be a BIG problem, because, some of my "components" are
> executables, which used in other projects.
> 
> Why, even if retaining all of the points below, it could not be
> executable and/or library.
> 

They are actually executables like any other. I just wanted to say that 
normally the user won't run them. But you will be able to use a executable 
both as a program and as a library if you want.

Regards,

-- 
Beno?t Minisini



From ronstk at ...124...  Wed Apr 21 11:54:52 2010
From: ronstk at ...124... (Ron_1st)
Date: Wed, 21 Apr 2010 10:54:52 +0100
Subject: [Gambas-devel] User components in Gambas 3
In-Reply-To: <l2lc42ff1b51004201458v53604457je14d5c7b4037fc39@...178...>
References: <201004202240.02466.gambas@...1...>
	<l2lc42ff1b51004201458v53604457je14d5c7b4037fc39@...178...>
Message-ID: <201004211154.53058.ronstk@...124...>

On Tuesday 20 April 2010, David Villalobos Cambronero wrote:
> 2010/4/20 Beno?t Minisini <gambas at ...1...>
> 
> > Hi,
> >
> > I post this mail on both mailing-lists: please answer on the developer
> > mailing-list if possible, as this is related to the development version!
> >
> > I'm currently thinking about how user components should work in Gambas 3,
> > as I
> > dislike the way it was designed in Gambas 2.
> >
> > In Gambas 2, user components work the same way as normal components made
> > with
> > Gambas, except that they are symbolic located in the home directory that
> > point
> > at the real executables.
> >
> > That design lead to many problems: you can't make packages of user
> > components
> > easily, and if the real executable moves, the symbolic link is broken while
> > the IDE think the component is there.
> >
> > So, for Gambas 3, I propose a different design:
> >
> > - There are no "user" components anymore.
> >
> > - Instead, a project will be able to depend on other projects.
> >
> > - The list of associated projects will be defined in the IDE project option
> > dialog.
> >
> > - That list will be just a list of project *names*.
> >
> > - At design time, these project will be search inside one or more
> > directories
> > that will be defined as a IDE global option.
> >
> > - At run time, the associated projects will be searched by using the $PATH
> > environmental variable, as any other executables.
> >
> > Consequently:
> >
> > - The IDE global option will tell where you store the projects you want to
> > use
> > as components.
> >
> > - These projects will be packaged separately and installed like any other
> > Gambas projects.
> >
> > - They should have a special name, because they are not real executables,
> > but
> > some sort of "Gambas" libraries instead.
> >
> > - So the project executables should be in the $PATH. And so the main
> > project
> > will find them easily.
> >
> > - When creating the main project packages, it will be easy to add a
> > dependency
> > on the associated project packages.
> >
> > I need to find a good term for these "associated" projects. I'd like to
> > find
> > something different than "component".
> >
> > Even if internally the interpreter will use the same code to load them, I
> > want
> > the user to understand easily that they do not work the same way.
> >
> > Maybe "library" would be a good term...
> >
> > What do you think about the new design?
> >
> > --
> > Beno?t Minisini
> >

why not use the /opt way?

/opt/gambas3/

/opt/gambas3/comp
/opt/gambas3/etc
/opt/gambas3/bin
/opt/gambas3/lib
/opt/gambas3/help
/opt/gambas3/share/project1
/opt/gambas3/share/project2
/opt/gambas3/tmp
/opt/gambas3/var
(just a example dir list)

this way it would/could be for everyone(distibution) the same.

Best regards,

Ron_1st

-- 



From fabianfloresvadell at ...176...  Wed Apr 21 18:08:03 2010
From: fabianfloresvadell at ...176... (=?ISO-8859-1?Q?Fabi=E1n_Flores_Vadell?=)
Date: Wed, 21 Apr 2010 13:08:03 -0300
Subject: [Gambas-devel] ValueBox
In-Reply-To: <201004180040.36370.gambas@...1...>
References: <p2nd0f8bc231004171136qef6c9f82g4398daa2d11e40ec@...178...>
	<201004180040.36370.gambas@...1...>
Message-ID: <q2md0f8bc231004210908j59f69262l902d2a815f987672@...178...>

> I won't do the previous methods, because TextBox is a native control in both
> gb.qt and gb.gtk, and so its methods must be native methods.
>
> All that is syntactic sugar that can be implemented by extending the TextBox
> directly in Gambas code.

OK, I understand.

> I don't see the need of the mask property outside of the TextBox or
> MaskedBox
> control, because it implies both formatting the displayed text and managing
> the key events.

I was thinking that the mask would be just a facility to do easier to
write patterns that determine what a control will accept as input. So,
if mask would be available as a Gambas class or simply a function,
could be used anywhere, and the Gambas user could use it for its own
purposes (e.g. to filter the input in a custom control).

> Don't forget that the user may want to edit just a date, just a time, or
> both
> date and time. The same DateBox control should allow all that. And have a
> popup calendar for the date part.

Yes.

> I'm not sure if using inheritance for implementing all the possible features
> of ValueBox is a good idea.

Why, do you think that?

I don't know if would be a good idea but I think than this should be explored.

Finally, what I want is find a good OO design, because I don't like
the idea of a very extensive class. I tend to think that this would be
a class write according to the paradigm modular / structured rather
than OO, and probably would result in poorly cohesive class.

What do you think?

> I'm not against DateBox, but I don't like having
> dozen of different controls for editing different things.

Oh, no. That isn't the idea. But the ValueBox could be a wrapper class
for diferent specifics controls.

> I prefer an unique interface, ValueBox, whose behaviour is entirely defined
> by
> its Type property.

Yes, I agree.

> Don't forget that I want to use this control in the GUI
> database component, to easily edit database fields. I want to let the user
> have an optional gambas-specific metadata table in its database, that the
> component will use to configure the ValueBox that will edit each field.

Absolutely. We agree about that, but the differences are about design.

Probably your perspective is correct, only that I still haven't clear.


-- 
Fabi?n Flores Vadell
www.speedbooksargentina.blogspot.com



From gambas at ...1...  Sun Apr 25 18:50:38 2010
From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=)
Date: Sun, 25 Apr 2010 18:50:38 +0200
Subject: [Gambas-devel] "User components" replaced by "Libraries" in Gambas 3
Message-ID: <201004251850.38369.gambas@...1...>

Hi,

In the last revision, I added the implementation of "libraries" in Gambas 3. 
That libraries completely replace the "user components" concept of Gambas 2.

How does it work?

You have a new tab named "libraries" in the IDE project property dialog. In 
that tab, you can define a list of gambas executables (*.gambas files) that 
will be used as libraries.

When adding a library to a project, the IDE will extract from it all the 
information needed for the automatic completion, as for the normal components.

These libraries will be loaded at program startup by the interpreter exactly 
like any component written in Gambas.

When your project in run in debugging mode, i.e. from the IDE, the libraries 
are located by using the absolute path specified in the project property 
dialog.

But when running the project normally, the library is searched in the 
following directory only:
- The same directory as the project.
- /usr/bin
- /bin

So, a Gambas executable that must act as a library for another program must be 
installed in /bin, /usr/bin, or in the same directory as the program using it.

Now I'm waiting for your comments about this new feature!

Regards,

-- 
Beno?t Minisini



From david.villalobos.c at ...176...  Mon Apr 26 16:06:19 2010
From: david.villalobos.c at ...176... (David Villalobos Cambronero)
Date: Mon, 26 Apr 2010 08:06:19 -0600
Subject: [Gambas-devel] "User components" replaced by "Libraries" in
	Gambas 3
In-Reply-To: <201004251850.38369.gambas@...1...>
References: <201004251850.38369.gambas@...1...>
Message-ID: <r2xc42ff1b51004260706x393b49b5j6c0541aec20bcbce@...178...>

2010/4/25 Beno?t Minisini <gambas at ...1...>

> Hi,
>
> In the last revision, I added the implementation of "libraries" in Gambas
> 3.
> That libraries completely replace the "user components" concept of Gambas
> 2.
>
> How does it work?
>
> You have a new tab named "libraries" in the IDE project property dialog. In
> that tab, you can define a list of gambas executables (*.gambas files) that
> will be used as libraries.
>
> When adding a library to a project, the IDE will extract from it all the
> information needed for the automatic completion, as for the normal
> components.
>
> These libraries will be loaded at program startup by the interpreter
> exactly
> like any component written in Gambas.
>
> When your project in run in debugging mode, i.e. from the IDE, the
> libraries
> are located by using the absolute path specified in the project property
> dialog.
>
> But when running the project normally, the library is searched in the
> following directory only:
> - The same directory as the project.
> - /usr/bin
> - /bin
>
> So, a Gambas executable that must act as a library for another program must
> be
> installed in /bin, /usr/bin, or in the same directory as the program using
> it.
>
> Now I'm waiting for your comments about this new feature!
>
> Regards,
>
> --
> Beno?t Minisini
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>

I think it will be nice to warm the user the paths were new application will
try to find the libraries, so he will keep it in mind.

-- 
Regards
---
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20100426/b58ededb/attachment.html>

From david.villalobos.c at ...176...  Mon Apr 26 17:25:32 2010
From: david.villalobos.c at ...176... (David Villalobos Cambronero)
Date: Mon, 26 Apr 2010 09:25:32 -0600
Subject: [Gambas-devel] Open remote files
Message-ID: <h2ic42ff1b51004260825r436024a7g2a889baab483bcf2@...178...>

Hi, can be implemented the opeing of remote files with Gambas? Maybe in the
same way KWrite?

-- 
Regards
---
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20100426/05b0ab0a/attachment.html>

From gambas at ...1...  Mon Apr 26 17:59:50 2010
From: gambas at ...1... (=?utf-8?q?Beno=C3=AEt_Minisini?=)
Date: Mon, 26 Apr 2010 17:59:50 +0200
Subject: [Gambas-devel] Open remote files
In-Reply-To: <h2ic42ff1b51004260825r436024a7g2a889baab483bcf2@...178...>
References: <h2ic42ff1b51004260825r436024a7g2a889baab483bcf2@...178...>
Message-ID: <201004261759.51020.gambas@...1...>

> Hi, can be implemented the opeing of remote files with Gambas? Maybe in the
> same way KWrite?

Big problem. I think the best at the moment is using the "fuse" library, which 
allows you to open any remote file as if it is local.

-- 
Beno?t Minisini



From david.villalobos.c at ...176...  Mon Apr 26 21:12:26 2010
From: david.villalobos.c at ...176... (David Villalobos Cambronero)
Date: Mon, 26 Apr 2010 13:12:26 -0600
Subject: [Gambas-devel] Error on Gambas3 using TabStrip
Message-ID: <s2ic42ff1b51004261212m327d060ka38d72f3ed640c97@...178...>

See the proyect attached and see the pic attached, the picture shows the
form that is shown at execution time.

 [OperatingSystem]

OperatingSystem=Linux

KernelRelease=2.6.31.12-desktop-3mnb

DistributionVendor=MandrivaLinux

DistributionRelease="Mandriva Linux 2010.0"


 [System]

CPUArchitecture=i686

TotalRam=2035740 kB


 [Gambas]

Gambas1=Not Installed

Gambas2=Not Installed

Gambas3=2.99.0

Gambas3Path=/usr/local/bin/gbx3


-- 
Gracias
---
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20100426/24164161/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w-0.0.1.tar.gz
Type: application/x-gzip
Size: 7247 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20100426/24164161/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Error2.png
Type: image/png
Size: 9168 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20100426/24164161/attachment.png>