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

"Dave Young" <da***************@softwarespectrum.comwrote in message
news:OB**************@TK2MSFTNGP02.phx.gbl...

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?

[Simon Tamman]

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

private Dictionary<string, stringhash = 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

"Dave Young" <da***************@softwarespectrum.comwrote in message
news:OB**************@TK2MSFTNGP02.phx.gbl...

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?

[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

On Mar 13, 11:16 am, "Dave Young"
<[e-mail]:

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?

[Bruce Wood]

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

On Mar 13, 1:49 pm, "Todos Menos [MSFT]"
<[e-mail]:

I don't really understand the point.

Can't you just use a database?

Is SQL Server more complex than this?

-Todos

On Mar 13, 11:16 am, "Dave Young"

<[e-mail]:

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?

[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.
"Todos Menos [MSFT]" <to**************@hotmail.comwrote in message
news:11*********************@b75g2000hsg.googlegro ups.com...

I don't really understand the point.

Can't you just use a database?

Is SQL Server more complex than this?

-Todos

On Mar 13, 11:16 am, "Dave Young"
<[e-mail]:

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?

[Jon Skeet [C# MVP]]

Simon Tamman <i_**********************************@NOSPAMhotmai l.com>
wrote:

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Simon Tamman]

Thanks for the tip. :D

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. :D

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Simon Tamman <i_**********************************@NOSPAMhotmai l.com>
wrote:

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[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



On Mar 13, 2:00 pm, "Bruce Wood" <[e-mail]:

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

On Mar 13, 1:49 pm, "Todos Menos[MSFT]"

<[e-mail]:

I don't really understand the point.

Can't you just use a database?

Is SQL Server more complex than this?

-Todos

On Mar 13, 11:16 am, "Dave Young"

<[e-mail]:

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?- Hide quoted text -

- Show quoted text -

[Jon Skeet [C# MVP]]

Simon Tamman <i_**********************************@NOSPAMhotmai l.com>
wrote:

Thanks for the tip. :D

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. :D

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

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[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

"Simon Tamman" <i_**********************************@NOSPAMhotmai l.com>
wrote in message news:In***************@newsfe4-gui.ntli.net...

>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 Menos [MSFT]" <to**************@hotmail.comwrote in message
news:11*********************@b75g2000hsg.googlegro ups.com...

>I don't really understand the point.

Can't you just use a database?

Is SQL Server more complex than this?

-Todos

On Mar 13, 11:16 am, "Dave Young"
<[e-mail]:

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?

[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

On Mar 13, 3:19 pm, Jon Skeet [C# MVP] <[e-mail]:

Simon Tamman <i_am_GETRIDOFTHISJUNKanti_everyth...@NOSPAMhotmai l.com>
wrote:

Thanks for the tip. :D

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. :D

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

--
Jon Skeet - <[e-mail]>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[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
On Mar 13, 2:13 pm, Jon Skeet [C# MVP] <[e-mail]:

Simon Tamman <i_am_GETRIDOFTHISJUNKanti_everyth...@NOSPAMhotmai l.com>
wrote:

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.

--
Jon Skeet - <[e-mail]>http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[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


On Mar 13, 12:21 pm, "Simon Tamman"
<i_am_GETRIDOFTHISJUNKanti_everyth...@NOSPAMhotmai l.comwrote:

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

private Dictionary<string, stringhash = 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

"Dave Young" <[e-mail] in message

news:OB**************@TK2MSFTNGP02.phx.gbl...

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?- 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" <dm************@verizon.netwrote in message
news:eF**************@TK2MSFTNGP06.phx.gbl...

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

"Simon Tamman" <i_**********************************@NOSPAMhotmai l.com>
wrote in message news:In***************@newsfe4-gui.ntli.net...

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 Menos [MSFT]" <to**************@hotmail.comwrote in message
news:11*********************@b75g2000hsg.googlegro ups.com...

I don't really understand the point.

Can't you just use a database?

Is SQL Server more complex than this?

-Todos

On Mar 13, 11:16 am, "Dave Young"
<[e-mail]:
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?

[Dave Young]

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

Thanks
"Simon Tamman" <i_**********************************@NOSPAMhotmai l.com>
wrote in message news:QE***************@newsfe5-win.ntli.net...

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" <dm************@verizon.netwrote in message
news:eF**************@TK2MSFTNGP06.phx.gbl...

>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

"Simon Tamman" <i_**********************************@NOSPAMhotmai l.com>
wrote in message news:In***************@newsfe4-gui.ntli.net...

>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 Menos [MSFT]" <to**************@hotmail.comwrote in message
news:11*********************@b75g2000hsg.googlegro ups.com...
I don't really understand the point.

Can't you just use a database?

Is SQL Server more complex than this?

-Todos

On Mar 13, 11:16 am, "Dave Young"
<[e-mail]:
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?