Dictionary Object name/value pair

[Dave Young]

I'm trying to replicate the behaviour of the Commerce.Dictionary object that
was found in Commerce Server 3.0

By using a hashtable or creating a custom class that implements IDictionary,
you have to add elements by using the following syntax.

DictionaryObject.Add("key","value");

However, the old Commerce Server Dictionary object used the following
syntax.

DictionaryObject.Name = "Fred"

In this instance, the dictionary object creates a new element key called
"Name" and assigns the value of "Fred" to it.

Any thoughts on how to replicate this?

 

[VJ]

What are probably looking to do is create a Dictionary Object and then a
Collection of Dictionary Object, so more like

Public class MyDictObj
{
// has member name
}

public class CMyDictObj : CollectionBase
{
// represents collection of MyDictObj
}

HTH
VJ

 

[Simon Tamman]

It's not perfect, but you could use an indexer to reduce the amount of
modification.

private Dictionary<string, string> hash = new Dictionary<string, string>();

public string this[string key]
{
get
{
return hash[key];
}
set
{
hash[key] = value;
}
}

Which means that instead of:

DictionaryObject.Name = "Fred"

you do:

DictionaryObject["Name"] = "Fred";

I think it's not possible to dynamically create properties as C# is a
statically typed language and you will get a compiler error if the property
you are asking for does not exist.

If you REALLY want it to work like this and don't care about bloat you could
write a codeGen to create a class file with every single alphabetical
combination created as a property.
As an example of A:

public string A
{
get
{
return hash["A"];
}
set
{
hash["A"] = value;
}
}

But that would be a seriously LONG file.

HTH

Simon

 

[Todos Menos [MSFT]]

I don't really understand the point.

Can't you just use a database?

Is SQL Server more complex than this?

-Todos

 

[Bruce Wood]

I believe that the OP is asking about an in-memory data structure, not
a long-term storage option.

 

[Simon Tamman]

I "think" he's trying to prop up existing code by re-writing this library.
If the API changes then more code needs to be re-written.
That's why I think he's not using a database.

I could be wrong though, if that's the case then you're right a database is
definately the best course of action. Because trying to create a dynamic
type in a statically typed language is like putting a square peg in a round
hole.

 

[Jon Skeet [C# MVP]]

I "think" he's trying to prop up existing code by re-writing this library.
If the API changes then more code needs to be re-written.
That's why I think he's not using a database.

I could be wrong though, if that's the case then you're right a database is
definately the best course of action. Because trying to create a dynamic
type in a statically typed language is like putting a square peg in a round
hole.

"Todos" isn't trying to make serious points - he's just trolling. Best
to ignore.

 

[Simon Tamman]

Thanks for the tip.

No chance I could get your opinion on my wierd bug I posted yesterday is
there?
I did include a "short but complete" example to demonstrate the problem.

 

[aaron.kempf]

I just think that we should be teaching these Newbies about DATABASES
and not all this ADO.net and XML _CRAP_

that is why we outsource all this crap to india-- because there aren't
enough kids in the good old USA that know how to speak SQL

 

[Jon Skeet [C# MVP]]

Thanks for the tip.

No chance I could get your opinion on my wierd bug I posted yesterday is
there?
I did include a "short but complete" example to demonstrate the problem.

Unfortunately I don't know a lot about the details of Windows Forms.
Have you asked in the Windows Forms newsgroup?

 

[Dave Young]

You are correct sir. There an old asp application that our company uses
that was originally built upon Site Server 3.0 and Commerce Server 3.0.

Well, one company aquisition and a datacenter migration tends to make one
want to eliminate, or at least reduce, the number of 3rd party applications
that need to be re-installed. I've been able to migrate all of the
previously used CS and SS dlls that were being used, to C#, but this one
eludes me. I originally attacked it by giving them (the asp dudes) a simple
implementation of IDictionary, but that didn't give them the same usage as
the original. Thus, my post.

If it can't be done, then I'll just tell them so and they can go back and
change their code to use the implementation I gave them.

Thanks
Dave

 

[Todos Menos [MSFT]]

yeah 'I dont know Windows forms'

the funny thing is that Iknow of about a hundred PHP kids that can
just flat out-develop these ASP.net fags

-Todos

 

[Todos Menos [MSFT]]

I'm not trolling

I'm throwing molotov cocktails against the oppressive regime in
Redmond

TIME FOR REGIME CHANGE IN REDMOND!

-Todos

 

[Todos Menos [MSFT]]

and really. seriously

I don't really understand the point.

Can't you just use a database?


Is SQL Server more complex than this?


-Todos

It's not perfect, but you could use an indexer to reduce the amount of
modification.

private Dictionary<string, string> hash = new Dictionary<string, string>();

public string this[string key]
{
get
{
return hash[key];
}
set
{
hash[key] = value;
}
}

Which means that instead of:

DictionaryObject.Name = "Fred"

you do:

DictionaryObject["Name"] = "Fred";

I think it's not possible to dynamically create properties as C# is a
statically typed language and you will get a compiler error if the property
you are asking for does not exist.

If you REALLY want it to work like this and don't care about bloat you could
write a codeGen to create a class file with every single alphabetical
combination created as a property.
As an example of A:

public string A
{
get
{
return hash["A"];}

set
{
hash["A"] = value;

}
}

But that would be a seriously LONG file.

HTH

Simon

I'm trying to replicate the behaviour of the Commerce.Dictionary object that
was found in Commerce Server 3.0

By using a hashtable or creating a custom class that implements IDictionary,
you have to add elements by using the following syntax.

However, the old Commerce Server Dictionary object used the following
syntax.

DictionaryObject.Name = "Fred"

In this instance, the dictionary object creates a new element key called
"Name" and assigns the value of "Fred" to it.

Any thoughts on how to replicate this?- Hide quoted text -

- Show quoted text -

 

[Simon Tamman]

Well to support the current implementation is it not possible to just
collate all the properties they are using and implement those? Or are there
way too many to implement?

I mean name could be implemented like:

public string Name
{
get
{
return hash["Name"];
}
set
{
hash["Name"] = value;
}
}

I guess it depends on how many dynamic tags they're using on this object.

 

[Dave Young]

That's one approach I hadn't thougth about.

Thanks

Well to support the current implementation is it not possible to just
collate all the properties they are using and implement those? Or are
there
way too many to implement?

I mean name could be implemented like:

public string Name
{
get
{
return hash["Name"];
}
set
{
hash["Name"] = value;
}
}

I guess it depends on how many dynamic tags they're using on this object.

You are correct sir. There an old asp application that our company uses
that was originally built upon Site Server 3.0 and Commerce Server 3.0.

Well, one company aquisition and a datacenter migration tends to make one
want to eliminate, or at least reduce, the number of 3rd party applications
that need to be re-installed. I've been able to migrate all of the
previously used CS and SS dlls that were being used, to C#, but this one
eludes me. I originally attacked it by giving them (the asp dudes) a simple
implementation of IDictionary, but that didn't give them the same usage
as
the original. Thus, my post.

If it can't be done, then I'll just tell them so and they can go back and
change their code to use the implementation I gave them.

Thanks
Dave