|
Why not use unsafe mode?  There's nothing wrong with it. 
"What lies behind us and what lies before us are small matters compared to what lies within us." -- Ralph Waldo Emerson
FLUID UI Toolkit
|
|
|
|
|
How to make an window application run one time?
I mean that an application just have 1 instance at a point of time.
Like in VB:
If (App.PrevInstance) Then
End
End If
thanks.
|
|
|
|
|
|
|
I'm trying to serialize an array of type "Person". The objects stored in the array are all derived from person and are stored like this:
Person[0] = Player
Person[1] = Coach
Person[2] = Player
The problem is I get the following error:
"An unhandled exception of type 'System.InvalidOperationException' occurred in system.xml.dll
Additional information: There was an error generating the XML document."
I'm using this line to initialize the Serializer: XmlSerializer y = new XmlSerializer(the_Game.PEOPLE.GetType());
It works fine when I use a BinaryFormatter, but not with the XmlSerializer. Any suggestions?
|
|
|
|
|
[rant]
The XmlSerializer has a bad name because it isn't a true serializer. More of a helper class that can spit basic data out as XML. There are two major downfalls with it.
1) It doesn't support inheritence very well. The type of the object declared is the type that gets serialized. Using your example of an array of Person objects (where Player, Coach, and Referree all inherit from Person) the XML that XmlSerializer (XS) spits out will only have the attributes that the Person object exposes.
2) It is only good for holding public data. Say your Person class has some private variables used to maintain state of some sort, for example a Position variable. This variable isn't exposed as a property because it is only of use to the methods within the Person class not its derivatives. This extra state variable isn't serialized by XS because it only searches for public properties and variables (maybe even protected ones, I can't remember).
On top of that all of the data types used by your class publicly, as well as the types they use, etc must all conform to certain restrictions: have a public, parameterless constructor; all public properties that are to be serialized need to be both read and write; and lastly, not use the IDictionary interface publicly this includes use of IDictionary and any class which implements it (XS specifically checks for it).
Unlike the XmlSerializer, the BinaryFormatter and the SoapFormatter are true serializers able to store all the information within an object.
[/rant]
That said, you should check that your Person class has a public parameterless constructor, and that it is not an abstract class (another restriction).
James
"then when you go to bed...wait, you dont do that do you....ok....when you plug into the 'hive mind' to charge yourself, ill hack into your head"
Nnamdi Onyeyiri over MSN
|
|
|
|
|
All the classes have a parameterless constructor that calls the base constructor(which is parameterless). I think I'll stick with the BinaryFormatter then. It would be nice to output the data as XML, but it's not a necessity.
Thanks, and how did you know I had a Referee class?
|
|
|
|
|
Hi, I'm having a bit of trouble understanding how Soapsuds ties in with Remoting. Quote:
"the idea behind SoapSuds is to run it on an existing assembly to extract the metadata for all MarshalByRefObject so that you don't need to deploy the complete implementation assembly to your clients."
>> Why'd you need to do that? I mean, if you don't want to distribute implementation, just distribute "interface" assembly. I don't see any need for soapsuds (what am i missing here?)
IngoRammer prefer not to use it because Soapsuds does not accomodate for serializable fields:
http://www.ingorammer.com/RemotingFAQ/SoapSudsOrInterfaces.html
Thanks!
norm
|
|
|
|
|
norm wrote:
Why'd you need to do that? I mean, if you don't want to distribute implementation, just distribute "interface" assembly. I don't see any need for soapsuds (what am i missing here?)
The "interface" assembly method stops you from doing a few things that you could want to do from remoting. If you have Ingo's book I think it was chapters 3 and 6 that included most of the reasons.
It's been a while since I've played with remoting (I got half way through chapter 6  ). But if I remember correctly, if you go the interface route you can't use server activated objects because, of course, you can't create an instance of an interface. It also stops you from making heavy use of configuration files for configuration and deploying of your server (or client).
Hope that gives you some ideas,
James
"then when you go to bed...wait, you dont do that do you....ok....when you plug into the 'hive mind' to charge yourself, ill hack into your head"
Nnamdi Onyeyiri over MSN
|
|
|
|
|
Thanks, first of all. Here's what I think.
If you adopts the interface-route, you can't use "new" keyword or instantiate a server object on client side - but you can still gain access to server object's state.
But I still don't see why we need to use Soapsuds (to generate a transparent proxy) even if we don't use "interface" - just add reference to the original assembly where the remotable class reside. Why bother generating another assembly with Soapsuds?
norm
|
|
|
|
|
norm wrote:
But I still don't see why we need to use Soapsuds (to generate a transparent proxy) even if we don't use "interface" - just add reference to the original assembly where the remotable class reside. Why bother generating another assembly with Soapsuds?
Here is where its starts to get murky for me; the only reason I can think of is that by adding a reference to the assembly housing your remoted class you then have to ship your remoted class to the end user. This is usually not desireable because it defeats one purpose of using remoting, keeping some of your implementation on another server where the end user can't decompile it.
If, however, you generate a proxy class with SoapSuds then you don't have to distribute your implementation of the remotable class.
James
"then when you go to bed...wait, you dont do that do you....ok....when you plug into the 'hive mind' to charge yourself, ill hack into your head"
Nnamdi Onyeyiri over MSN
|
|
|
|
|
I don't think that defeats the purpose - your remote object still resides on the remote server.
Yes, you will need to either ship your assembly to your end user or put the assembly in webroot or designated folder. But still, the client just extract type information from it. The actual object still runs on a process on remote server machine: For example, it can still access database and other resources on the remote server (client my rely on the server object to gain access to certain resources residing on remote server).
norm
|
|
|
|
|
I have drwan something on a picturebox. How can I give priting capability to user? Firstly showing a print preview is a good idea! Is there any straightforward solution?
Don't forget, that's Persian Gulf not Arabian gulf!
|
|
|
|
|
Does .NET have an equivilent to the Win32 API GetWindowPlacement?
Or is there an article on preserving window size and placement here (and I just didn't search right?)
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
|
Perfect!
Thanks.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
I am making a .NET wrapper for a C library. In the process, I came across a number of structs. Some of these structs need to be used from .NET, and some do not.
In one struct, there is a pointer to a structure, CallInfo, which is used by the C application, but need not be touched by the .NET application. I don't want to have to declare the CallInfo structure in .NET, because it is big and has lots of unions. Since in C, this member is a pointer to an instance of that struct, I assume that I can just declare this member as an IntPtr, and be done with it. Am I correct?
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi
|
|
|
|
|
You should be ok; I can't think of anything that would cause problems.
James
"then when you go to bed...wait, you dont do that do you....ok....when you plug into the 'hive mind' to charge yourself, ill hack into your head"
Nnamdi Onyeyiri over MSN
|
|
|
|
|
OK... that's what I thought, but I wanted to be sure.
"Blessed are the peacemakers, for they shall be called sons of God." -- Jesus
FLUID UI Toolkit
|
|
|
|
|
Im currently in the process of programming an application that renders video to a textured object in 3d (for starters I just use a square consisting of two triangles with a texture)
for testing purposes I run the application in windowed mode and the object displays just fine.
problem is when I run in fullscreen mode the object does NOT display. I use font.Drawtext() to display text and it displays just fine..
hope you guys can help!!
|
|
|
|
|
I'm trying to delete a value from the registry like this:
RegistryKey key = Microsoft.Win32.Registry.CurrentUser;
string keyName = "Software\\" + Application.CompanyName + "\\" + Application.ProductName + "\\Test";
RegistryKey subKey = key.OpenSubKey(keyName);
RegistryPermission rp = new RegistryPermission(RegistryPermissionAccess.Write, "HKEY_CURRENT_USER\\" + keyName);
if (subKey != null)
subKey.DeleteValue("DeleteMe");
and I'm getting this exception:
System.UnauthorizedAccessException: Cannot write to the registry key.
Any ideas?
Thanks,
Alvaro
Can I ask you a question?
|
|
|
|
|
|
|
I found the problem. I needed to use the other version of OpenSubKey (and pass it true). The RegistryPermission code isn't even needed:
RegistryKey key = Microsoft.Win32.Registry.CurrentUser;
string keyName = "Software\\" + Application.CompanyName + "\\" + Application.ProductName + "\\Test";
RegistryKey subKey = key.OpenSubKey(keyName, true);
RegistryPermission rp = new RegistryPermission(RegistryPermissionAccess.Write, "HKEY_CURRENT_USER\\" + keyName);
if (subKey != null)
subKey.DeleteValue("DeleteMe");
Regards,
Alvaro
Can I ask you a question?
|
|
|
|
|
Use regedt32.exe and see if the current use actually has rights to the key.
Also instead of using
RegistryKey subKey = key.OpenSubKey(keyName);
use :
RegistryKey subKey = key.CreateSubKey(keyName);
using CreateSubKey will give you a writable value. I think.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
