code economy

[netbumbler]

I'm in the process of writing some extensive logic algorithms (lots of if-then-else) to interrogate poorly formatted text data files. What I'd like to do is streamline the code such that I can create a function to call into my main sub but have access to all the main subs variables (without having to re-establish variables and such). Is the best way to do this with global vars? Or is there a better way? Does my question make sense enough?
Thanks,
Chris

 

[TheAceMan1]

How are ya netbumbler . . .

. . . and whats wrong with [blue]passing the variables[/blue] to the function?

See Ya! . . . . . .

 

[netbumbler]

AceMan1,
The problem is this... I'm using several stub counters and flags as I step my way through this text file and passing and keeping track of this and additionally, reporting back the HAM, if you will, makes structuring such a function that's expecting a position and returning the data back again (not to mention the sequence of this data is quite strange and troubling to the mind to say the least, but not beyond the wiles of carefully crafted logic) hence, the need to 'codify' an extensive logic loop that can be called on at different intervals with these repeating if-then-else constructs and having access to the root procedure's variables throughout the process.
In my old C/C++ programming days, I remember using #INCLUDES to inject files into the code stream - is there not a way to do something like that in VBA?
Thoughts?
Thanks,
Chris

 

[EBGreen]

You can use globals. I am a fan of the Law of Demeter and I try to decouple procedures from each other as much as possible. To this end, I would dictionary to decouple. I would have the main script create a dictionary that had entries for all of the flags/counters/variables/whatever you need to maintain the sate of your parsing. Then simply pass that dictionary around to whatever functions you are using for the parsing. If you need a more complex data structure, then I would define a custom class with whatever structure that you need.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[netbumbler]

TomThumbKP,
Thanks for the pointer... that's was the way I was beginning to lean (global variables). However, you mention 'dictionary' - but this is new to me... is it designed use as a variable type operation? I'll have to dig some more here.
Chris

 

[EBGreen]

Notice that I said you could use globals. I by no means espouse this position. As a matter of fact I usually do everything I can to avoid using globals. If you have used Perl or Python, then a dictionary is essentially the same as a hash. It lets you define name - value pairs where the name is some constant (usually a string) and the value can be anything including other dictionaries or objects. With something like this you could store all of your state information about the condition of the file and simply pass the dictionary to whatever function needs to know the state of the file.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[netbumbler]

So a dictionary is 'globally persistent' data, I presume?

 

[EBGreen]

No. It is local, but it is one object that you can pass to a function when you call it.

[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]

 

[warthog72]

I like the class object use; and use it frequently with my apps - storing and using variables between forms. Properties for each variable and you should be good.

 

[MichaelRed]

I usualy generate a couple of routines for this type of stufffffffffffffffffffffff. One to just grab the text file. Itf it has any type of tregular structure or delimiters, another to seperate the "records" into "fields". Mostly, I would use actual fields in a temp table, as this provides the complete relational db functionallity. Sometines, it is just as easy to create a UDT and pack hte "fields" into the UDT structure. This (latter) cinstructs is acceptable if you are just working with one to a few records, as the UDT can be passed to (and recieved back from) procedures. You can aslo create arrays of UDTs and pass them as well.




MichaelRed