[Gambas-devel] Passing things

[Dan Phillips]

My biggest thing is, _how_ do I use all these forms if none of them can talk 
to one another.  It'd be like having a bunch of different programs running 
and none of them know about the other guy.

If you can demonstrate how a form, say form1 can be up on the screen w/ a 
handful of options and another form, say form2 can be on the screen as well.  
And information modified on form2 needs to be shown on form1, how do you do 
that?  Any code that can truely demonstrate how to do that will help.  As you 
can tell from my previous posts, coming from vb and knowing how to do it 
there sort of makes it hard to work in Gambas because I don't know how to 
talk to various parts of my program.

It's not a "have to have this feature" thing, it's more of a, "don't know how" 
thing.  Although, in my mind, it's better programming _not_ to have anymore 
code in the form than absolutely necessary.  My method of programming has led 
me to do 90% or more of my code in modules that talk to the forms as needed.  
Because events aren't raised outside of the form in VB but on the object 
itself, take a command button for instance.  When someone clicks the button, 
the command1_click() event is raised.  so I have something like this:

Command button OK

public sub command1_click()
	'Need to call save routine for options dialog box
	SaveSettings
end sub

This allows me to have a module that _is_ resusable for any type of project 
and I simply cut/paste the sections of code I need for project 2, 3, etc.

However, the SaveSettings subroutine that is in module1 needs to be able to 
directly work with the information located on frmOptions.  

Like I've shown, I just don't know how to do programming otherwise is my 
problem of jumping to Gambas.  

Now, to defend Gambas, I think that the Gui is very comfortable looking and I 
think that so far it is a great product.  The work that has been put into 
making the code easy to work with has obviously taken some serious volunteer 
time by people willing to do it and that's awesome.  If I could assist in 
this I would certainly do so, unfortunately my skills are just too limited to 
do so.


On Wednesday 14 May 2003 08:52, Benoit Minisini wrote:
> Le Lundi 12 Mai 2003 05:23, Ken Schrock a écrit :
> > Sorry about posting to the wrong list
> > And thanks for answering my question anyway : -)
> > Particularly since it doesn't look like I will be using it anyway
> > Anal retentive, overbearing, "modular", "tightly scoped", "object
> > oriented" Languages just keep me going back to C
> >
> > Since this is the developers form...
> > Come on guys, seriously, I mean really...
> >
> > Form1.Listbox1.Insert(Textbox1.Text)
> >  (or its equivalent in C)
> >
> > Is simple, clean, elegant, intuitive, logical
> > Your two examples are none of those things
> > Think about it, think about the hoops you make people jump through
> > Just to pass a single simple string from a client window to a parent
> > window
> >
> > This may get you an award from an egghead language designer's group
> > But nobody will use it. That is fine if that is what you really want to
> > do However, if you want anybody to use it, you have to rethink this I'm
> > not going to go through all that and nobody else will either
> >
> > It is a shame, as it is an excellent idea, and well executed
> > But it appears crippled by dictatorial design philosophy
> > And really, we don't need any more of that kind
> > The landscape is littered with plenty already
>
> I don't want to say that VB programmers are "bad", but that they tend to
> use bad programming practices. I didn't want to hurt you, or anyone else.
>
> I'm going to try to explain why, even if it is difficult for me to do that
> in English.
>
> Whatever you think about object-oriented programming, encapsulation is the
> way to write good programs, even if the language you use is not
> object-oriented.
>
> In a few words, encapsulation is a programming process achieved by:
>
> 1) Separating your program into different pieces.
>
> 2) Minimizing the links between these pieces to make reusability, debugging
> and evolution easy.
>
> In concrete terms, I dislike accessing controls outside their forms,
> because it creates unnecessary links between two pieces of your program:
> the form, and the code that access it from outside.
>
> You can see forms as a high-level encapsulation unit imposed by the
> language.
>
> For example, let's suppose you have a form Form1 with a list box ListBox1,
> and that you directly modify this list box from a Form2.
>
> If you decide to replace later the list box by a list view, you must then
> modify Form2 to reflect the change. So you have broken the encapsulation
> provided by the forms.
>
> *Of course*, I am agree with you, it is stupid to replace a single line of
> code by all the stuff just for "philosophical" reasons. But if you must
> write and *maintain* a program with hundreds of classes and forms, you will
> like encapsulation ! :-)
>
> And to show everybody that I am not crippled by dictatorial design
> philosophy
>
> :-), I will add an option to the next version of the Gambas compiler to
> : make
>
> form controls public.
>
> I hope this will help VB programmers to port their program more easily, but
> I reserve the right to claim that encapsulation is a good thing for
> everyone, even it need a few more, apparently stupid, lines of code.

-- 
-----------------------
-Thanks, Dan
-Haight & Associates, Inc.
-907.586.9788
-----------------------