|
I have a bunch of different structs that implement IMyType. I also have some more advanced structs that are essentially containers for x number of IMyType instances (they are not lists). They need to be iterated so I am implementing IEnumerable<IMyType>. At the moment I have made a custom enumerator that has a params IMyType[] myTypes parameter in the contructor and using this type of code in the IEnumerable structs:
public IEnumerator<IMyType> GetEnumerator()
{
return new MyTypeEnumerator(
new IMyType[] {
new MyType(...),
new MyTypeOther(...) });
}
This works fine but I've been considering getting rid of the MyTypeEnumerator and using this instead:
public IEnumerator<IMyType> GetEnumerator()
{
IEnumerable<IMyType> collection = new IMyType[] {
new MyType(...),
new MyTypeOther(...) };
return collection.GetEnumerator();
}
Obviously both work just fine and are pretty much identical. Which would you prefer?
Edit: Alternatively, I could just use return new MyTypeEnumerator(this); and let the MyTypeEnumerator take care of it. I don't like that idea - ignore
modified 27-Oct-12 10:19am.
|
|
|
|
|
You'd normally only create a custom enumerator if you want to be able to enumerate the (virtual) collection without holding the whole list in memory all at once. So I don't quite understand the purpose of your implementation. If you can define a list form for your object, why not just expose that?
public IList<IMyType> Items {
get {
IList<IMyType> list = new List<IMyType>();
list.Add(new MyType(...));
list.Add(new MyTypeOther(...));
return list;
}
}
public IEnumerator<IMyType> GetEnumerator() { return Items.GetEnumerator(); }
Actually you don't need to implement IEnumerable at all if you do that, you can put the List property on the interface and users can do foreach(IMyType item in myObject.Items) instead of foreach(IMyType item in myObject).
|
|
|
|
|
There is another class that has a method:
public void Send(IEnumerable<IMyType> collection)
{
foreach(IMyType myType in collection)
{
}
}
This is the only place the IEnumerable is used (no need for any sort of list at all), so that leaves the second method as the prefered, essentially what your list is doing but without the list.
|
|
|
|
|
But the point is you are creating the list anyway (well, an array to be precise, but it's pretty much the same thing). However, implementing only IEnumerable and not IList (or exposing a list) implies that the enumeration can be run without the whole thing being in memory all at once.
It would be cleaner to expose the list and to pass that to Send (i.e. instead of calling Send(myObject), call Send(myObject.Items), to my mind.
|
|
|
|
|
I see where you're coming from. Richard's solution below is the best for this particular situation I think as the array doesn't actually need to be in memory all at once. I can simply create the instances as required using yield return directly.
Thanks for your input though, it has helped clarify some of my thinking in regards to iterators and foreach which will be helpful in future, and encouraged me to dig deeper into the whole thing that I previously just took for granted 
|
|
|
|
|
Another alternative to consider:
public IEnumerator<IMyType> GetEnumerator()
{
yield return new MyType(...);
yield return new MyTypeOther(...);
...
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Good thinking, much better creating the new IMyTypes as needed. 5d 
|
|
|
|
|
As was said earlier, there is not much reason to create a custom enumerator these days. The reason for an enumerator is to be able to use the ForEach loop. The Yield statement. Then there is also LINQ, Not sure why you are even bothering with an Enumerator given the alternatives avaialable.
|
|
|
|
|
Clifford Nelson wrote: there is not much reason to create a custom enumerator these days
That's why I asked, it felt somewhat unnecessary.
Clifford Nelson wrote: Not sure why you are even bothering with an Enumerator given the alternatives
avaialable
There are many types in the library that are responsible for creating multiple instances of the interface IMyType (the quantity and implementation differs by the type) when required, and all these types need to be able to be passed to one common method so it can iterate over the interface instances - IEnumerable<IMyType> fits this scenario/concept perfectly, what is was designed for IMO.
|
|
|
|
|
hey guys , i hav a dll file and i want to add this dll file in my c#.net project reference . i knw ,i can do this by simple clicking,copying and paste but i want to do this through a program.
pls help me
as i ma newbie.
thanks
|
|
|
|
|
References don't exist at runtime so you're question doesn't make any sense.
Are you talking about using this .DLL as a "plugin"?? You can try reading this[^].
|
|
|
|
|
prani_partner wrote: i hav a dll file and i want to add this dll file in my c#.net project reference . i knw ,i can do this by simple clicking,copying and paste but i want to do this through a program.
You can create macro's in Visual Studio, and yes, you can manipulate the IDE from code. However, when would this type of AddIn execute? Probably when the user initiates it, say, by clicking somewhere.
..or are you referring to the "using" group at the top of the file?
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
|
I just made a very simple app.
Enter some numbers, click a button, program calculates a result.
I tried to build a "release" version.
Ugh.
I want a simple executable file where the user can click and it runs, without going through an installation procedure.
I have searched here and MSDN for...
"BUILDING A C# APPLICATION THAT DOES NOT HAVE TO BE INSTALLED"
... and I'm finding zero and a little bit less.
This is a simple practice program, 24 instructions, 75 lines total, all just click click and it puts a number on the screen.
What did I miss ? Please tell me this can be done. I want to show my boss that I am capable of doing something; if only a simple thing.
|
|
|
|
|
- Code and debug the app.
- Switch the configuration to "Release" and rebuild.
- Give the app's release mode
.exe to your boss to run.
/ravi
|
|
|
|
|
Actually all you have to do is go into the bin\Debug (or what ever folder you want), and pick up the exe from there. The pdb file contains the debug information, and you can actually attach to the process and debug with the pdb containing the symbols.
|
|
|
|
|
C-P-User-3 wrote: What did I miss ? Please tell me this can be done.
All applications have dependencies, and .NET application depend on the correct .NET framework to be installed. We're not talking about native code here that you compile, but some kind of portable executable.
If you target-machine has all the prerequisites (correct .NET framework, various service packs) then you could do a simple xcopy and move the executable, as noted by the others.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
I have been working on a WPF application and looking for the best way to implement the 'Ok' and 'Cancel' button click functionality in the modal dialog boxes.
The question has two parts:
Part -1:
Currently, I am doing it by creating a copy/clone of the actual object whenever we load the dialog. Later, I perform all the operations on the cloned object in the Modal dialog. If user press 'Ok', i'll assign all the values in the clone object to the actual object. If user press 'Cancel, i'll discard the cloned object and set it to null.
For E.g:
Suppose, I have a class Person
<pre lang="c#">
Class Person
{
public string FirstName {get; set;}
public string LastName {get; set;}
}</pre>
I have another class which holds the list of 'Person'
Class PersonContainer
{
public List<Person> Persons{get; set;}
}
We have a Window class 'PersonViewModel' which has all the things with respect to the view. This class has a ObservableCollection which is bound to a Datagrid in my View and properties 'FirstName and LastName' are bound to the columns of the Datagrid.
The view contains button to 'Add/Remove/Modify' the records and 'Ok' and 'Cancel' button.
suppose we have PersonContainer object 'originalContainer' with 2 records. In the load event of the view, we create a copy/clone of PersonContainer with 2 records. Let's call it as clonedContainer. When we perform any operation(Add/Remove/Modify) through the dialog, we do it on clonedContainer. Once, we are done, on press of 'Ok' button, we just update originalContainer with the clonedContainer. On press of 'Cancel', we discard the 'clonedContainer' and set it to null.
Q: what could be the best way to handle 'Ok' and 'Cancel' in a dialog? Is creating a cloned object right way?
Part 2:
I have to implement the undo/redo of all the actions(Add/Remove/Modify the record) that happened on the Dialog. This has been implemented through the ICommand pattern with Execute/Unexecute methods. Whenever, we add a record, we add it the through the Execute method. However, we use the clonedContainer object and not the real one. In the Unexecute, I am using the 'originalContainer' instance and remove the added Person object. Now, if we perform 'Redo', we need to create the removed 'Person' object. By this time, clonedContainer is no more as it has been destroyed once we close the dialog.
Q: How can we implement undo/redo here?
Thanks in advance!!!
Rags
|
|
|
|
|
I don't know why you cloned the object, if the collection keeps the current record, you can save the index of it and if cancel is clicked, remove from the collection and only save when the save button is click, here is a small sample, just play with this and see if it can help you.
1-You need to implement commanding in your project (you are already doing it)
2-in your view
link you button to a command in your viewmodel
Example a Save button:
4-remember your imports, this way you can display on the view the message for the user to answer and don't need to clone.
|
|
|
|
|
Thanks for the response!
Here I have used Person, PersonContainer and PersonViewModel just for representation. In actual scenario, the object is complex which updates many of its properties on Addition/modification of items in the datagrid. So, saving the index won't serve the purpose as we need the actual values.
Can you elaborate more on the 'imports' mentioned on #4? Still, i believe we need to clone the actual object and work on it. Appreciate, if you can help me a little detailed code.
- Rags
|
|
|
|
|
Rags1512 wrote: Q: what could be the best way to handle 'Ok' and 'Cancel' in a dialog? Is creating a cloned object right way?
There is no "right" way, there are only efficient, inefficient and non-compiling implementations. FWIW, I'm doing something similar; I clone the object and throw it in a PropertyEditor. Has a third button that says "reset" that simply clones the original again and uploads it anew in the PropertyEditor. Works well, doesn't have much overhead.
Rags1512 wrote: Q: How can we implement undo/redo here?
An undo/redo is usually limited to the form where one is editing. You'd need the Memento-pattern, saving the internal state of the object every time the user performs an action. Undoing the action is then as simple as fetching the internal state from that point.
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks for the response!
Looks like memento pattern is the solution. Let me understand and try it.
-- modified 27-Oct-12 14:15pm.
|
|
|
|
|
Like Eddy said, there is no right or wrong to do it, using observable collections, you could have 2 and a flag, if the record is dirty (meaning that was modify) then in the save event in your viewmodel you just save the record, if cancel was hit and it was dirty then restore from either the db. again (re-read the record) or copy it from the other collection. What I mean with the 'imports' is that the 'Message' needs a import on the viewmodel.
|
|
|
|
|
There are essentially two ways to do this. The first is what you've done: copy the object, have the dialog operate on that copy, and update the original if you press OK. The second is rather similar, but instead of having a copy of the base data object to operate on, you operate on a specific data object for the form (i.e. it has properties for the fields that are editable on this form only), and if you press OK you assign all the properties from that data object into the source.
In the second case the data object can actually be the form itself, particularly with WPF's data binding that allows you to have UI controls display numbers, enum choices etc simply. This is normally what I do.
Re undo/redo, you need to save a command when you change the original object, i.e. press OK. Do you need to be able to undo each thing individually? ... I would normally expect 'Edit Object' to end up as a single undo action which is easier (you just have a command which stores the properties that were changed and the previous value, or even the whole before and after states, of the source object). If you do need undo entries for every dialog interaction then you need to have a local command stack within the dialog, and when you save the object you can execute them all in order on the source object and push them onto the global undo stack against that object.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
