OpenEuphoria

1. win32lib: Munafa Accounting Package

• Posted by Anando Banerjee <anandobanerjee at rediffmail.com> Jul 03, 2005
• 558 views
• Last edited Jul 04, 2005

Hi,

Munafa Accounting Package, using only Euphoria/win32lib, is available at
http://www.rapideuphoria.com/munafademo.zip.

This is the program that I had been facing problems with, especially Error 461
with DropDownLists. Thus far, I can see that Resource Meter goes from around 68%
free to around 38% free as soon as Munafa starts and back to 68% free when I exit
Munafa. I assume 30% is way too much. How can that be resolved for a package like
Munafa which needs multiple windows?

Any other suggestions?

Thanks & regards.
Anando

3. Re: win32lib: Munafa Accounting Package

• Posted by Jason Gade <jaygade at gmail.com> Jul 03, 2005
• 527 views
• Last edited Jul 04, 2005

Anando Banerjee wrote:
> 
> 
> posted by: Anando Banerjee <anandobanerjee at rediffmail.com>
> 
> Hi,
> 
> Munafa Accounting Package, using only Euphoria/win32lib, is available at
> http://www.rapideuphoria.com/munafademo.zip.
> 
> This is the program that I had been facing problems with, especially Error 461
> with DropDownLists. Thus far, I can see that Resource Meter goes from around 68%
> free to around 38% free as soon as Munafa starts and back to 68% free when I exit
> Munafa. I assume 30% is way too much. How can that be resolved for a package like
> Munafa which needs multiple windows?
> 
> Any other suggestions?
> 
> Thanks & regards.
> Anando

Okay, so what's the password?


-- 
==============================
Too many freaks, not enough circuses.
j.

5. Re: win32lib: Munafa Accounting Package

• Posted by Anando Banerjee <anandobanerjee at rediffmail.com> Jul 04, 2005
• 534 views
• Last edited Jul 05, 2005

Anando Banerjee wrote:
> 
> Am unable to disclose source code at present. But everything is simple:
> Each menu item is a separate 'include' file.
> Each 'include' file is a window with it's controls.
> 

As you can the program starts off with a huge bunch of local constants hogging
loads of memory.
constant SomeWindow=create(Window, ...)
constant SomeControl=create(EditText, ...)
and so on.

The actual project I am working on is even bigger and will have lots more
user-interactive windows.

My question is: how can I reduce the number of local constant windows at
start-up and create only the constants (windows) the user clicks for. When the
user exits the window, how can I release the constant until it is required again?

destroy() removes the constant all together, closeWindow() keeps it in memory.
Is there something else I am missing?

Thanks & regards.
Anando

7. Re: win32lib: Munafa Accounting Package

• Posted by Anando Banerjee <anandobanerjee at rediffmail.com> Jul 05, 2005
• 557 views

Thanks Pete,

Pete Lomax wrote:
> 
> so you don't want to give away the source, you may need to be prepared
> to spend several days creating something which demonstrates the 
> problem, that you are prepared to release.
> 

I am sure you understand 
1. that the code is big - over 21,000 lines already, with some of it being
embarassingly repetitive (but I am still learning & wouldn't want to misguide
other newbies on an open forum),
2. that this type of code is more owner-need-based & custom-designed than
intellectual/educational (like the extra pockets in a travelling salesman's
shirts, trousers, jacket), hence the owners may not want to disclose the source
at such an early stage of development,
3. that, even then, seniors with a broader knowledge of the language will be
able to quickly understand the newbie-but-handicapped programmer's use of syntax
& logic flow without access to the source code (that's primarily why I
contributed the Munafa demo at this time and not later).

Given the above, I am sure that all of us freshers are grateful for the patience
& help from the seniors in this forum. The occassional ragging, teasing &
admonitions are all part of the learning process, I guess, and shouldn't drive
away the true, persistent learner. Euphoria, because of its people, is truly
turning out to be "easier than BASIC, more powerful than C".

Regarding the example you have cited below, I see that you have declared the
variables as local integers, not global or private constants. Then you have
initialized them within a procedure. Now, my questions:

1. destroy() in this case would remove the variable & make it inaccessible the
next time the user wants the same window. E.g. user searches for some text,
closes the window, does something else without leaving the program & again comes
back to search for some other text. Since closing the search window has already
destroyed the window variable, how is the local variable (search window)
declared/created again when required?

2. Local variables (in all include files) get created at program start using up
lots of memory (a start-up of the Munafa demo with Windows Resource Meter active
will show that). Or is there some other way around? You have mentioned .ini file,
a little more guidance on how to implement?

3. If the variables are declared as private, how does another procedure 
access them? E.g. a user-data-change in one variable (say Bill Number field)
triggers an onChange event which should change the data displayed in other
fields/variables (Debtor, Products, Amounts, Totals, etc.). The changed variable
itself may be accessed with the "self" parameter but what about the numerous
other variables?

> I often code something like the following:
> 
> }}}
<eucode>
> integer initFIND, Fwin
> 		initFIND=0
> 
> integer flab, findtext, rlab, replacetext, 
> 		...
> global procedure Find()
> 	if not initFIND then
> 		Fwin = create( Window, "Find", 0, Main, 100, 50, 523, 190,0)
> 		flab = create( Label, "Find ", 0, Fwin, 8, 15, 70, 24,0)
> 		findtext = create( ComboDropDown, "", 0, Fwin, 80, 11, 305, 
> 		...
> 		initFIND = 1
> 	end if
> <font color="#330033"></eucode>
{{{
</font>
> 
> (Another reason I have done that is to delay
> load of the .ini file until later, so I can reference all the various
> globals immediately each .ini setting is realised.)
> 

Basically my problem, at this stage, is accessing the relevant variables as and
when required instead of gobbling up memory by loading everything at program
start.

Thanks again for your patient guidance.
Regards.
Anando

9. Re: win32lib: Munafa Accounting Package

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jul 05, 2005
• 561 views

On Tue, 05 Jul 2005 01:29:48 -0700, Anando Banerjee
<guest at RapidEuphoria.com> wrote:

>Pete Lomax wrote:
>> 
>> so you don't want to give away the source, you may need to be prepared
>> to spend several days creating something which demonstrates the 
>> problem, that you are prepared to release.
>> 
>
>I am sure you understand 
<snip>
Yes, I do. I apologise if it sounded like I was attacking your 
decision not to release source; I was not. I had a similar situation 
with Print Preview, when I did not want to release the sources, but I 
needed to ask for help. In order to achieve a resolution, I needed to 
"waste" significant effort creating something which replicated the 
problem, though as it solved the issue, it was worth it. (And I hope a
few people were grateful that I tracked down an obscure and 
long-standing bug in the runtime system.) My intention was to outline 
the cost of such a decision, since I have direct experience of it.

I know that sounds daunting (I was not exaggerating when I said it 
took me three days), I was just sowing the idea that at some point you
may need to "bite the bullet". Let's hope not )

>Regarding the example you have cited below, I see that you have 
>declared the variables as local integers, not global or private 
>constants. Then you have initialized them within a procedure. Now, my 
>questions:
>
>1. destroy() in this case would remove the variable & make it 
>inaccessible the next time the user wants the same window. E.g. user 
>searches for some text, closes the window, does something else without 
>leaving the program & again comes back to search for some other text. 
>Since closing the search window has already destroyed the window 
>variable, how is the local variable (search window) declared/created 
>again when required?
See initFIND. Note that destroy() does not "remove the variable", it
"undoes" the create statement. The variable will still exist, though
its value will be meaningless. The next time Find() is called, it will
call create() again, overwriting the meaningless value with one than
can be used.
>
>2. Local variables (in all include files) get created at program start 
>using up lots of memory (a start-up of the Munafa demo with Windows 
>Resource Meter active will show that). Or is there some other way 
>around?
Variables themselves take up very little space. 21,000 (unassigned)
variables might use up as much as 500K of main memory, which is nearly
insignificant (less than 1% of physical memory on a 128MB box). More
significant, but still not critical, is the data those variables hold,
though I have managed to load 200MB of data on a box with only 48MB of
physical memory. However, the problem you are experiencing, I believe,
is the gdi/user/kernel resources used by defining all windows and
controls. Windows has fairly severe limits on these, something like
64K, I think.

BTW, for comparison, what does Resource Meter drop to when you load
the IDE?

The method I suggested will mean that Fwin will take up zero gdi
resources until Find() is called, and if you call destroy when the
window is closed (and reset initFIND so it will be recreated again
when next needed), then those important gdi resources will be
released.

>You have mentioned .ini file, a little more guidance on how to implement?
Download Mike's ini file contribution from the archives. .ini files
hold permanent settings, they don't resolve anything to do with excess
memory use.
>
>3. If the variables are declared as private, how does another 
>procedure access them?
a) make them global. This leads to the problem of name clashes.
b) add global getter/setter routines, eg

integer Fwin
global function getFwin()
	return Fwin
end function
global procedure setFwin(integer newvalue)
	Fwin=newvalue
end procedure

More code, but less error-prone.

c) In the example I gave, you would call the global procedure Find()
rather than openWindow(Fwin,Normal), so Fwin would not need to be
global, which, where possible, is the best solution.

>> I often code something like the following:
>> 
>> }}}
<eucode>
>> integer initFIND, Fwin
>> 		initFIND=0
>> 
>> integer flab, findtext, rlab, replacetext, 
>> 		...
>> global procedure Find()
>> 	if not initFIND then
>> 		Fwin = create( Window, "Find", 0, Main, 100, 50, 523, 190,0)
>> 		flab = create( Label, "Find ", 0, Fwin, 8, 15, 70, 24,0)
>> 		findtext = create( ComboDropDown, "", 0, Fwin, 80, 11, 305, 
>> 		...
>> 		initFIND = 1
>> 	end if
>> <font color="#330033"></eucode>
{{{
</font>
>> 
>> (Another reason I have done that is to delay
>> load of the .ini file until later, so I can reference all the various
>> globals immediately each .ini setting is realised.)
>> 
>
>Basically my problem, at this stage, is accessing the relevant variables as and
>when required instead of gobbling up memory by loading everything at program
>start.
>
>Thanks again for your patient guidance.
No problem, however please remember the above is just a suggestion, I
can offer no guarantee it will actually help.

Regards,
Pete