|
I'll try that at work tomorrow ...
I'm guessing the point you're making is ... the same namespace in the same DLL running on both machines, versus the exact same namespace compiled into two distinct executables. My question is then, how will it deal with versioning? The messages can, and mostly likely will, change with the version of the program suite. I'll then have the same namespace in two differently versioned DLLs -- two different DLLs containing differently versioned messages on the two machines. They must still exchange messages, with the versioning controlled by the support in serialization. Am I going to have the same issue then?
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
Hah another RAH fan 
I would think that if your message structure changes so dramatically that it cannot inherit from the original there is a fault in the design! I would expect it to become another message type.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I wouldn't say it would change dramatically, but for a given release one message out of the 25 or so total may add a single field. That's why I wanted to use the versioning support in serialization. I've done this lots of times before, but those were C / C++ program where I did it manually with just simple byte transfers where I would read a length, a type, a version and then deal with putting the different versions into the the message that came out of the receive function. Wasn't C# supposed to make this stuff easier? ... handling versioning (mostly) for you, and the ability to serialize and transfer something beyond an agnostic byte stream. If I can't even have the exact same code compiled into a different executable unit and have something in that namespace transfer between those units, I'll just trash the C# serialize portion of the transfer and go back to doing it manually. I must be able to have different versions running on different machines communicate with each other.
What I'm trying to do can't be that unusual. Do I need to transfer structures instead of classes? I've only been doing C# for about 2 years -- I've got the feeling I'm just missing something ...
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
I think I may be missing something as, while I use WCF, I don't do any messaging as such.
I use Dave's method of externalising the models (I use Silverlight) and reference them from both client and service. I have not had any issues with differing versions, I do know a missing field in the sent object is ignored by the deserialiser and ends up with a null value.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I haven't used binary serialization but XML will try to fill in all the data it can from the serialization data. If there's a field that isn't there in the data, it just won't get filled. If there is an extra field in the data that doesn't have a coresponding field in the object, it gets ignored.
...IIRC...
|
|
|
|
|
Moving the messages into their own namespace in their own DLL fixed the problem. I tested the versioning as well and it works fine. Looks like C# doesn't consider identically defined elements of an identically named namespace to be the same if they come out of two different executable units (i.e. my two original different EXEs); but they are the same if they come out of two different versions of the same executable unit (i.e. the new DLL).
Thanks Dave!!
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
Part of the fully qualified name of the object is the assembly its defined in. Two assemblies can have the namespace names in them but still be different objects.
|
|
|
|
|
That explains it then! I'll add that tidbit to the C# file in my brain. Would have been nice if the exception message showed the fully-qualified name instead of telling me that 'x' couldn't be typecast to 'x' 
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
I want devexpress winforms control can somebody give me that
regards
|
|
|
|
|
Not unless you pay DevExpress some money. You might want to check into doing that here[^]
|
|
|
|
|
Nobody will give you the controls, but you can always opt to take the radical option and offer them money for their work. This money will then go towards improving the controls and adding new features. It's a radical experiment, and we hope that it catches on.
|
|
|
|
|
naseer861 wrote: I want devexpress winforms control
You can download a trial version direct from the DevExpress website.
|
|
|
|
|
If you can't afford to purchase the commercial control sets you are going to have to limit yourself to the default controls. Only use the trial versions if you can afford to purchase, otherwise it is a waste of time.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hi All. I have a slight problem in that my DirectoryInfo does not return the full path. Does anybody know if there is a limitation to the DirectoryInfo?
The path to the files is something like this:
C:\\Folder1\\Folder2\\Folder3\\Folder4\\Folder5
My code is as follows:
private void getAllFiles(string sExt, string sFolder)
{
DirectoryInfo di = new DirectoryInfo(sFolder);
FileInfo[] fi = di.GetFiles(sExt, SearchOption.AllDirectories);
foreach (FileInfo file in fi)
{
AddNewFile(Path.Combine(di.ToString(), file.ToString()));
counter++;
}
lblTotalFiles.Text = counter.ToString();
}
FileInfo seems to get the location of the file as it shows me the file it picked up but when the path of DirectoryIfo is passed on it excludes Folder5 thus the object I am passing it to doesn't find the file in question. Is there anyway I can fix this?
Excellence is doing ordinary things extraordinarily well.
|
|
|
|
|
Kwagga wrote: FileInfo[] fi = di.GetFiles(sExt, SearchOption.AllDirectories);
....
Path.Combine(di.ToString(), file.ToString())
These lines may not be doing what you assume. SearchOption.AllDirectories tells GetFiles to search the starting directory and all subdirectories. The ToString() method of FileInfo's created by GetFiles returns just the filename without any path information. Your use of Path.Combine creates the correct full path only for files in the starting directory.
If your aim is to pass the full path of each file to the AddNewFile method just use the FileInfo.FullName property without Path.Combine.
i.e. AddNewFile(file.FullName);
Alan.
|
|
|
|
|
Thanks Alan. That resolved my issue. Greatly appreciated.
Excellence is doing ordinary things extraordinarily well.
|
|
|
|
|
We are going to add a USB connection to our system.
I am estimating that this will at least double the speed of transmission from the little box to the PC/GUI.
There is a real possibility that we will send the data at 10x the existing speed. Maybe 14x
The GUI amasses 8192 bytes per second, and draws 20 graphs from that one second.
The samples will still be one second apart, they will just jump across ten times faster.
Has anyone gone through this biz before ? Is there anything my GUI/PC guy needs to beef up in the GUI to handle this ? He has a thread for the data reception and a thread for the graphing of that data.
|
|
|
|
|
That really depends on how the threads communicate. Does the data reception thread send the data to the GUI thread, or does the GUI poll the data thread. Also important: where and how is the data stored.
The biggest issues I foresee are that your data thread could become too fast for the GUI thread and the latter starts lagging behind, or when the GUI thread locks some resource that this could cause the data thread to hang on the lock too much to keep up with the increased data.
|
|
|
|
|
public enum Type
{
None = 0,
Found =1,
NotAval = 2
};
public enum ShortType
{
None = 0,
Fd =1,
NA = 2
};
class Properties
{
public Type type;
};
List<Properties> props;
...
...
//
|
|
|
|
|
Can you avoid that situation in the first place? Cast immediately while populating that list, for example. Or cast when getting the items out of the list.
ptr_Electron wrote:
Not happening. At least, not really. Someone will probably suggest LINQ's Cast<T>[^], but all that does is change a normal loop into a lazy loop.
|
|
|
|
|
|
Go back and fix the problem. If you want long and short names you might be interested in a DescriptionAttribute.
|
|
|
|
|
|
Even if you could cast a List<T> to a different type, (which you can't without playing silly buggers a lot) you couldn't do what you want: the list is not of the enum, it is a List of the Class containing the enum, which is a very, very different item indeed.
Summing you want to do this to have human readable names for your enum elements, have a look at this: Human readable strings for enum elements[^]
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
If the enums are in your sources, try the solutions already suggested.
But if you cannot change the sources (e.g. Third Party), you may add a wrapper class - thus actually introducing a third enum which you use in your application, and whenever you need to communicate with Third Party, the wrapper does the translation. Not a nice solution, but feasable.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
