Page 2 of 2
Posted: Fri Dec 22, 2006 5:58 pm
by Kaeru Gaman
good point...
maybe the information is outdated.
I based my sentence "enumerating with other start-numbers or with gaps will
cause no Error but may lower Performance. " on this information....
Posted: Fri Dec 22, 2006 6:07 pm
by netmaestro
OK, you're right - I didn't actually open Window Two in my first test. It uses the memory dynamically, so I saw a noticeable increase (around 300k) with Enumeration 4990 compared to #PB_Compiler_EnumerationValue when I actually opened the window.
Posted: Sat Dec 23, 2006 6:20 pm
by NoahPhense
Ok, now I'm lost. Can someone put that into perspective, and show
an example of good vrs bad?
- np
Posted: Sun Dec 24, 2006 3:45 am
by netmaestro
It's not a huge deal. Basically, it's just an issue of how much memory you're setting aside for gadgets by your choice of gadget numbers. For readability, I numbered my objects 0-99 for the main window, 100-199 for Window 1 and 200+ for Window 2. In doing so, when I open Window 2, enough memory gets set aside to store data for 200 gadgets because I left gaps in the numbers. We're not talking about a lot of memory here, just a couple of k. Using Enumeration #PB_Compiler_EnumerationValue to start your Enumeration blocks allows you to start a new enumeration for code readablility without creating gaps in the enumerations. For example:
Code: Select all
Enumeration ; starts at 0
#This ; 0
#That ; 1
#TheOther ; 2
EndEnumeration
Enumeration #PB_Compiler_EnumerationValue ; picks up where the last block left off
#MoreThis ; 3
#MoreThat ; 4
EndEnumeration
Enumeration 100 ; starts at 100, leaving a large gap in the numbers used for objects/gadgets
#MoreYet ; 100
#MoreStill ; 101
Endenumeration
Personally, I think the few extra k of memory used by the program at runtime is worth the extra readability / debuggability of being able to look at a gadget number and instantly know where it belongs. But that's a personal preference, for someone else the idea of creating a program that uses the smallest memory footprint possible is more attractive. Both viewpoints are valid and have strong/weak points. But in the end we're only talking about a memory allocation far less than one megabyte in size, so it's not a dealbreaker either way.
Posted: Sun Dec 24, 2006 1:26 pm
by Kale
ts-soft wrote:@netmaestro
Code: Select all
Enumeration ;Window One
#wOne
#wOne_Txt_Text1
#wOne_Btn_Button1
EndEnumeration
Enumeration #PB_Compiler_EnumerationValue ; Window Two
#wTwo
#wTwo_Txt_Text1
#wTwo_Btn_Button1
EndEnumeration
thats a bit long winded.
Better like this:
Code: Select all
Enumeration
;window1
#wOne
#wOne_Txt_Text1
#wOne_Btn_Button1
;window2
#wTwo
#wTwo_Txt_Text1
#wTwo_Btn_Button1
EndEnumeration
Posted: Sun Dec 24, 2006 1:29 pm
by netmaestro
You're quite right, Kale, the #PB_Compiler_EnumerationValue is generally more usefull in code-generation scenarios, I often use the comments myself.
Event Managing w/main loop and Multiple Window forms
Posted: Wed May 02, 2012 11:01 pm
by Tenaja
I know this is an old thread, but I was looking for a "best practice" technique for this, and the post came in handy. I could think of a few ways to do it, but after seeing the samples here, I have made up my mind. Special thanks to you, netmaestro, for a great sample that will scale up well. (My "main loop" was already 8 pages long, and adding windows was getting it crazy!)