Visability of a Stack?

[mud2]

Nevermind why! I use a stack to save data. The stack is declared in a class module, and an instance is defined by my program. I want to push data in one sub, and pop it in another. How do I make this stack "public". Defining an instance of this stack as Public does not work.

I can do this with an array, but the stack (once working) makes keeping an array index easier, and putting it in a class allows other features such as knowing and returning the stack size.

[mud2]

Talk about Not seeing the forest for the trees......
I'm sorry!
All I have to do is write the stack in a separate module, with Private array and stack possitions, and Public Push Subs and Pop Functions.
Don't even need the separate module, but it's cleaner that way.
Now That I've "solved" the problem, I'll try it out!

[xCav8r]

I know you solved your own problem, but I'm curious about why you're taking this approach. I don't say this to question what you're doing, but I would be interesting in learning why you're doing this, because maybe it's something I should be doing as well.

[mud2]

Subject: Re: Reply to post 'Visability of a Stack?'Never ask an ex-professor
a "Simple" question

> Hello mud2,
>
> xCav8r has just replied to a thread you have subscribed to entitled -
Visability of a Stack? - in the Access Help forum of VBA Express Forum.
>
> I know you solved your own problem, but I'm curious about why you're
taking this approach. I don't say this to question what you're doing, but I
would be interesting in learning why you're doing this, because maybe it's
something I should be doing as well.

Thanks for the interest. My "Stack problem" is solved, although niot as
simply as I thought. It was necesary to include an incremented Static
variable(?) in the PUSH to initialize the stack pointer and the Array the
stack uses.

You asked for it!
I'm setting up a db to record my photographs. It will contain several
tables; 1. An "Original" table, each record will contain data about an
individual roll of film: A unique ID, its location, speed, etc, and a field
with comma or space delimited "keys" describing the contents of the roll.
2. Another table with similar data covering CDs burned from a roll of film,
with a "Directory" of the CD (WOW, that's a mess. I can do it but there's no
simple DOS type 'DIR" command), and key words for the CD and for chosen
files (images) on the CD.
3. Still another table, with data about CDs burned from Photoshop-processed
images in the previous tables. Again with directories and KEY words.

So far, Table 1:
Data is entered either directly to the table, or to a form based on the
table. Once the data is in the table I "read" the field with the key words,
Parse the keys, and PUSH these keys to a stack. Next I POP these keys to a
"KeyTable", and remove duplicate keys from this table. The KeyTable is used
as the source of a list box, from which I chose a key and execute a Query
(with a "Like" condition taken from the clicked-on list box) to find those
records that contain that key.

I have completed the previous paragraph...covering the Original table.
I have set up a switchboard that directs me to different processes...

Parsing, and pushing are done in one sub, Popping to the keytable in a
different Sub, and checking for duplicate keys in still a different sub.
The reason for these different subs is so that I can used them over again
when processing other tables. They are, or will be, called with variable
arguments.

Most of this is done using recordsets instead of various querys. Reason?
Because most times when I have (thought) completed a step and come back to
repeat it, I've received error messages...such as "this record is locked".
When I work with the recordset itself I don't (so far) have this trouble!

There's a long way to go yet!

And what will I do when I go "Digital"