Hi there

I understand that in order to store data globally you need to use a
public static variable.  What I want to know is this:

How do I make the contents of that variable persist in memory after
the program has finished?

The plan is to have a public static Dictionary <key, value> variable
such that each time the program is run a new key is generated and the
key/value pair is added to the Dictionary.  Thus the Dictionary grows
with each run of the program.

Can anyone tell me how to do that please?

On Nov 26, 1:21 pm, pinkfloydfan <lloyd.greens***@googlemail.com>
wrote:
It sounds like you don't want it to persist in *memory* but on *disk*.
Look up serialization in MSDN - that's probably the easiest way to go.

Jon

Thanks Jon, but no I don't want to serialise it I do want it to
persist in memory...in much the same way that a VBA public global
variable will...

On Nov 26, 1:43 pm, pinkfloydfan <lloyd.greens***@googlemail.com>
wrote:
Which process would you expect to hold this value, bearing in mind
that you're talking about the *program* finishing?

What about if the user reboots the computer?

Jon

All good points Jon...maybe I should explain more:

1)  I am writing some Excel functions in C# that will be wrapped in an
XLL.
2)  One of those functions "builds" some core data and gives it a key
3)  Other functions then use the key to reference the correct data set
and produce their own results.
4)  There may be more than set of core data.

So, if a user runs the "build" function it should store the core data
along with its key somewhere that it can be retrieved from later when
needed by other functions.

Thus, I was thinking I need to create a Dictionary that can persist in
memory.

Please understand, I am quite obviously a newbie and maybe I am going
about this all wrong so would appreciate any guidance.

Thanks very much

On Nov 26, 2:20 pm, pinkfloydfan <lloyd.greens***@googlemail.com>
wrote:
Show quoteHide quoteSo what is the logical scope of this data? Is it the Excel document
that the user currently has open? Is it the Excel process itself?

If you can work that out, that will probably suggest where it should
be kept.

Jon

Once the data had been built (in any spreadsheet) then its key would
be accessible to any other spreadsheet wishing to get at it.

I just thought that if this can be stored in memory (and I have
managed it with VBA) then surely retrieving the data has got to be
quicker than storing it to disk?

Cheers

On 2007-11-26 08:21:46 -0800, pinkfloydfan
<lloyd.greens***@googlemail.com> said:

How have you managed it with VBA?

The comments you've received have been accurate, and would apply in VBA
as well.  Which means that we're simply not getting a precise
description of what it is you want to do.

This is a C# newsgroup, but posting the VBA code you've already written
would not be off-topic in this case and would probably go a long way
toward helping us understand exactly what it is you expect to happen.

Pete

pinkfloydfan <lloyd.greens***@googlemail.com> wrote:
Any other spreadsheet within the open process, or within any process?
What happens if Excel is closed and then reopened?

Do you really have so much data that speed is an issue? Persisting to
disk is likely to be the simplest solution, if it addresses the need.

Dear Jon and Pete

To answer your questions in turn:

What happens if Excel is closed and then reopened?

Only spreadsheets within the open process.  If Excel is closed you
lose the data.

The way I achieved this was to store the data (object) in a Collection
defined at the Global level of a Class in VBA.  Each member of the
Collection can then be accessed via its own key and various operations/
tests can be performed on it.

disk is likely to be the simplest solution, if it addresses the need.

Well, I am building a monte carlo model that runs hundreds of
thousands of simulations and I want to be able to perform operations/
tests on that model once it is built.  If you have to either rebuild
the base data each time you want to perform an operation/test on that
data or re-load it from a disk I thought that has got to be a lot
slower than storing it in memory.  Additionally, there may be more
than one type of simulation run (with different initial states and
model parameters) and so in order to know which state the operations/
tests should be performed on I want to be able to access each state
via a key.

The whole point of rewriting my code in C# from VBA is for speed as
well as security.

Overall then, the idea is to create Excel functions that separately
"Build" the model and perform the various operations on that built
model where the specific model to perform those operations on is held
in memory and identified/accessed via a unique key.

Please understand that I am entirely self-taught at VBA and am just
learning C# now so I apologise if my mixing of VBA & C# is causing
anyone a headache

Thanks for your help

On 2007-11-27 00:47:57 -0800, pinkfloydfan
<lloyd.greens***@googlemail.com> said:

IMHO, this is the key.  You are doing it successfully in VBA, and while
that's not exactly the same as a .NET Framework application, it does
suggest you should be able to do the equivalent somehow in C#.

Going back to your first post, I'm wondering if we couldn't have helped
you better by simply taking you a little less literally.  You are
describing your code as "the program".  To most of us, that implies
you've got a standalone application running as its own process.

But, from your description of the VBA, it sounds as though it may be
you simply load a C# DLL into Excel and it remains loaded for each
execution.  You don't have a "program" that ends.  You just keep
calling the DLL.

If that's correct, then what you want to do is probably simple.  Just
declare a field in an appropriate class (perhaps the main class
managing the whole thing) that has the "static" attribute.  Then as
long as that DLL remains loaded, whatever you store in that field will
remain there.

If that doesn't work, then it might be useful to be more explicit about
the part of your description that applies to how your code is used. 
Specifically, when you write "some Excel functions in C# that will be
wrapped in an XLL", what do you mean exactly?

What's an "Excel function in C#"?  IMHO, an "Excel function" is mainly
a built-in function, and alternatively you can extend Excel by writing
a function in VBA.  But once you leave that environment, a function
isn't an Excel function.  It's some more general-purpose function that
you import into Excel.  So, do you just mean you've written some
general-purpose function that you want to import into Excel?  Or does
your code have some tighter connection to Excel that we're not thinking
of?

And what's "wrapped in an XLL"?  Are you simply compiling your C# code
as a DLL suitable for use in Excel as an XLL?  It's been awhile, but my
recollection is that an XLL is just a DLL renamed, accessed from Excel
through the usual VBA DLL import mechanism (I don't even recall how
XLL's worked with XLMs...that's too long ago, and surely it's not
relevant here :) ).  Is that what you're doing?  Or have you actually
written some non-C# wrapper for your C# DLL that proxies the C# DLL to
Excel?

Well, if anything your mixing of VBA and C# takes you outside what's
likely the expertise of most of us.  I can't speak for the others, but
even for me having had a fair amount of experience using VBA with
Office applications, I don't generally have the need to integrate my
VBA with external code, and haven't _ever_ had the occasion to need to
do it with C# code.

I'm not saying that no one here knows how to do things like that, but I
wouldn't expect it to be a commonly held piece of knowledge.

That said, we're generally fast learners.  :)  If you can explain in
more detail the specifics of how you've integrated your C# code with
your Excel VBA code, it's possible that will help lead to a better
answer.

That is, of course, assuming that for some reason a static field in one
of your C# classes doesn't do the trick.  And if it doesn't, it would
be helpful if you could explain why it doesn't.  That would probably
help with our understanding of what it is exactly you're trying to do.

Pete

Pete

Thanks very much for your kind response.  I think you are right: I
used poor language here.

For you guide, you have given me much more credit than I am due: I am
not mixing C# with VBA but rather am rewriting all my VBA classes and
modules in C#.  I am using ExcelDNA in order that the public static
functions within the compiled DLL are visible to Excel as separate
functions.  So my C# functions become Excel functions (in the language
I used above)!

If I understand you correctly, you are saying that if I store anything
in a public static field then as long as the DLL is loaded in Excel
then the contents of that field will stay in memory.  If so, then
that's great and it solves my problem. I will try it out and let you
know.

Thanks again

Fantastic! It works!

Thanks a lot

Show quote Hide quote The data cannot be left "alone" in the memory the way you want. If you want
to have the data available in memory then you need a process to host and
serve that data.

In the same way if you want to save the data for later use you should save
it in disk. Just take a look at Serialization as Jon's suggested in his
first reply.

Equals() and inheritance
Are Linq-SQL methods commutative
LINQ Question (Contains)
How about this syntactic candy?
C# Code Checker