1. Binding multiple source files
Hi,
Am relatively new to Euphoria and have successfully completed a few small
(single-form) programs.
I have also purchased the Binder and successfully tested the .exe's on other
computers.
My question is:
If I want to develop a big project, say an Accounting package with lots of input
forms, reports, sub-menus, etc., then I want to keep the source code for each
form/report/etc. in a separate file and finally bind them together to produce one
.exe for distribution. The smaller source files would be easier to
correct/update/etc. (Compare to Clipper wherein we used to create .prg's and then
used to compile and link to produce .exe's.) Is this possible and how do I call
routines and procedures in different files from a menu system in one file?
Thanks.
Anando
2. Re: Binding multiple source files
>>> guest at RapidEuphoria.com 02/09/2005 4:06:10 AM >>>
> posted by: Anando Banerjee <anandobanerjee at rediffmail.com>
> Am relatively new to Euphoria and have successfully completed a few
small (single-form) programs.
Welcome!
> If I want to develop a big project, say an Accounting package with
lots of input forms, reports, sub-menus, etc., then I want to keep the
> source code for each form/report/etc. in a separate file and finally
bind them together to produce one .exe for distribution. The smaller
> source files would be easier to correct/update/etc. (Compare to
Clipper wherein we used to create .prg's and then used to compile and
> link to produce .exe's.) Is this possible and how do I call routines
and procedures in different files from a menu system in one file?
There is a POS system that I started a number of years ago in Euphoria,
and a couple fellow members of this group are helping me update
presently, at http://sourceforge.net/projects/storemgr. This is laid
out modularly in much the same way as you are planning. Hopefully this
will give you some ideas on how to get started.
HTH,
Mike Sabal
3. Re: Binding multiple source files
On Wed, 09 Feb 2005 01:06:10 -0800, Anando Banerjee
<guest at RapidEuphoria.com> wrote:
<snip>
>Is this possible and how do I call routines and procedures in
>different files from a menu system in one file?
Yes, using globals.
Some tips (don't worry if you don't grasp all this in one sitting).
The second half of this should answer your question:
Try to keep all data local, for example it is generally better to
code:
integer Flag
global procedure setFlag(integer newValue)
Flag=newValue
end procedure
global function getFlag()
return Flag
end function
than it is to just code:
global integer Flag
The reason for this is often called "pollution of the global
namespace", which I will come back to in a moment. See also PS
First, though, you need to understand something called "scope":
for loop
routine
file
global
What on earth does that mean? It means three things:
First, when Eupohria is compiling/interpreting your program,
and processing a line such as "if i=5 then", it first looks for the
variable i in the surrounding for loop(s), then in the parameters
and local variables of the current routine, then among the variables
defined locally in the current source file (NB: whether or not they
are global), and finally in the global pool.
Secondly, it means that it is legal to define hundreds of variables
called i, provided they are defined at different scope levels, with
the small catch that you cannot define another i in the for loop scope
if it has already been defined at the routine level or a surrounding
for loop scope, nor can you define both a local (file-level) i and a
global i in the same source file.
Thirdly, if there is more than one global definition of "i", it must
be referred to using a namespace qualifier. Ideally, you would
ensure than all global names are unique, however as the application
grows, it becomes increasingly difficult, if not outright impossible,
to remember the names of all globals throughout the system.
Going back to the phrase "pollution of the global namespace", we find
that having duplicate global routines is far easier to manage than
duplicate global data names. Why? Well, compare the following two
coding errors:
--integer Flag -- we "forgot" this
Flag = 1
vs:
--procedure setFlag(...) -- we "forgot" this
setFlag(1)
Now, as they stand, both these will do exactly the same thing, namely
trash the "Flag" variable defined months or years ago in an entirely
different source file, and hence cause the new code to break old code,
sometimes in a very subtle unnoticed way. However, it is simply much
less likely that a programmer will make the second error, ie call a
routine without realising it is in another module. It probably also
has something to do with the fact that most programs have many more
data variables than routines, and secondly that routines only have two
possible scopes (file and global), not four.
Lastly, getting back to the question actually asked, a word or two on
namespaces, something I almost never use, but probably should.
You are not forced to use namespaces if the global is unique, but it
is usually a good idea to do so anyway. Suppose that:
fonts.e defines global Initialise(), and
colours.e also defines global Initialise()
Any and all calling programs should:
include fonts.e as fonts
include colours.e as colours
...
fonts:Initialise()
...
colours:Initialise()
If you write the fonts routine first, and call it without qualifiers,
you may find yourself adding them later, or worse, rename
the second as InitialiseColours() and change it in 6 places it is
called from, but miss one. I believe that much of the grief people
have with globals (myself included) stems from not using namespaces
as a matter of habit (but let's not get into an argument about that).
It is also possible to have eg:
main.exw:
global procedure redraw()
include fonts.e as fonts
and
fonts.e:
include main.exw as main
main:redraw()
Even though fonts.e can only "see" globals defined in main.exw before
the include fonts.e statement. The include main.e line does not create
another copy of the routines and data, it merely allows reference via
the main: qualifier.
Regards,
Pete
PS in the first example, the code in the same file as integer Flag can
just use it normally instead of calling setFlag/getFlag, which is what
code in other source files must do.
4. Re: Binding multiple source files
Mike Sabal wrote:
> presently, at <a
> href="http://sourceforge.net/projects/storemgr.">http://sourceforge.net/projects/storemgr.</a>
> This is laid
Mike:
That Link returns this message:
Invalid Project
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.ew
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
5. Re: Binding multiple source files
Bernie Ryan wrote:
>
> Mike Sabal wrote:
> > presently, at <a
> > href="http://sourceforge.net/projects/storemgr.">http://sourceforge.net/projects/storemgr.</a>
> This is laid</font></i>
>
> Mike:
> That Link returns this message:
>
> Invalid Project
EuForum included the '.' in the hyperlink. Delete the period and you'll
get the correct page.
Matt Lewis
6. Re: Binding multiple source files
Anando Banerjee wrote:
<snip>
> My question is:
> If I want to develop a big project, say an Accounting package with lots of
> input forms,
> reports, sub-menus, etc., then I want to keep the source code for each
> form/report/etc.
> in a separate file and finally bind them together to produce one .exe for
> distribution.
> The smaller source files would be easier to correct/update/etc. (Compare to
> Clipper
> wherein we used to create .prg's and then used to compile and link to produce
> .exe's.)
> Is this possible and how do I call routines and procedures in different files
> from
> a menu system in one file?
>
> Thanks.
> Anando
>
look in the archive for my recipient editor as an example.
This is a win32 module, which you initialize by passing the
name of your main window, call set_events to enable event processing,
and then a show procedure to make the window appear.
--"ask about our layaway plan".
--
7. Re: Binding multiple source files
Pete Lomax wrote:
<snip>
> Some tips (don't worry if you don't grasp all this in one sitting).
> The second half of this should answer your question:
>
> Try to keep all data local, for example it is generally better to
> code:
> integer Flag
> global procedure setFlag(integer newValue)
> Flag=newValue
> end procedure
> global function getFlag()
> return Flag
> end function
<snip>
That's a pretty well explained peice. You should make that a FNAQ
(Freqently not asked question ;this is a family freindly place so
I didn't want to make it 'frequently unasked question')
--"ask about our layaway plan".
--
8. Re: Binding multiple source files
- Posted by Pete Lomax <petelomax at blueyonder.co.uk>
Feb 09, 2005
-
Last edited Feb 10, 2005
I wrote:
><snip>
>>Is this possible and how do I call routines and procedures in
>>different files from a menu system in one file?
>
>Yes, using globals.
A simpler answer might have been define the menus near the end of the
program (but still before WinMain). For example in Edita, eamenus.ew
is included on line 1237 of 1939, and is 8th out of 9 include files,
so it can call anything defined in well over 2/3rds of the code. It
could even be much further down, apart from one routine
(toggleSpecials) , which is there to avoid making ToolShowS global.
Regards,
Pete
9. Re: Binding multiple source files
Thanks to Pete, Matt, Michael, Mike et al
for the responses to my question.
It works with "include" ing the separate files and setting up global variables
etc.
Euphoria is excellent ... once you get the hang of it.
I wish there were more (simple) .edb examples & tutorials.
But, I will make those separate questions (threads).
Thanks again.
Anando
