... edit #1 ...
If you really want to store a pair consisting of an int and a string, not two strings as shown in your original post, which came out in your later exchange in comments with LanFanNinja, then change the code below to use Tuple<int, string>, and "do the right thing" to define two look-up functions: one that returns a string, and one that returns an int.
The code shown below deals only with a pair of strings.
... end edit #1 ...
It may help you to think of an Array[#n1, #n2] as like a chess-board: at any one location, the "address," specified by the "row" index, and "column" index: there can be only one chess-piece.
It seems here you are trying to store two strings in each location in the Array.
The other thing you need to think about here, in my opinion, is that you are storing strings as 'objects,' and that means they will be "boxed" when you store them, and when you retrieve them, as objects, you will have to cast them back to Type String to use them
as strings: that's expensive, and not "best practice." So this will not compile:
private object[,] objAry = new object[1,1];
objAry[0, 0] = "string1";
objAry[0, 1] = "string2";
object o1 = objAry[0, 0];
string newString = o1;
There are several alternate ways you could go about getting what you want in .NET, including the use of a Dictionary, but let's look at a simple solution here using the Tuple object:
private Tuple<string, string> tupleEntryPlaceHolder;
private List<Tuple<string, string>> tupleList = new List<Tuple<string, string>>();
How do you add a new Tuple with your pair of strings to the List:
tupleEntryPlaceHolder = Tuple.Create("document1", "1");
tupleList.Add(tupleEntryPlaceHolder);
How do you access the elements inside a specific item, like item #0, in your List of Tuples:
string result1 = tupleList[0].Item1;
string result2 = tupleList[0].Item2;
To make access a little easier, let's define a function for that:
private string getTuple(int tupleIndex, bool isItem1)
{
tupleEntryPlaceHolder = tupleList[tupleIndex];
return isItem1 ? tupleEntryPlaceHolder .Item1 : tupleEntryPlaceHolder .Item2;
}
So now, you can access like this:
string result1 = getTuple(0, true);
string result2 = getTuple(0, false);
Here you have a solution that will be fast, and efficient, to use, will not require "unboxing" to get your stored strings back into Type String to be able to use them as Strings.
As I mentioned, this could also be done using other data-structure objects in .NET, like a Dictionary<string, string>, for example. And, perhaps, someone else, on this thread will respond with another type of solution.
By the way, there are "raw" forms of the Tuple object that can handle up to eight items per Tuple, and you can even extend a Tuple beyond eight items per Tuple by sticking another Tuple inside the Tuple definition. See:[
^] ... and:[
^]
... edit #2 ...
An important consideration to keep in mind in considering whether to implement a solution like this, with a Dictionary, or a Tuple, or a whatever, is the issue of possible duplicate key values.
For a generic Dictionary, adding an item with a duplicate Key will cause a run-time error of Type 'ArgumentException.
Yes, you can hack the equivalent of a Dictionary that allows duplicate keys, and if you search on CodeProject, you'll find some discussions/articles on this, but, the solutions are complex, and often they are "controversial," as you'll see if you read the comments.
At C-SharpCorner is an interesting two-part series, "A Dictionary class which permits duplicate keys" by Vulpes[
^],[
^], that provides a good overview on the considerations for design of a duplicate Key collection entity, and a very professionally coded and commented source-code example.
For a Tuple, adding an item with the same Key will not cause a compile error, or run-time error, but will simply replace the Value of that one Key item.
And, finally, for the use of the "older" data-structure, the HashTable, you also have error issues of adding duplicate key errors possible, and, the need to cast the results of a look-up back to some "original" Type.
... end edit #2 ...