|
You need to use the admin share, C$ (\\SERVERNAME\C#). Recursively enumerating the files will be quite slow remotely, however. You might consider - if possible - using .NET Remoting or some other remote technology to tell the server to search it's own hard drive (much faster) and report back to you the results (whether you're filtering or not, whatever fulfills your requirements).
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks for that. Only need to search for Directories not files.
Will look into it.
|
|
|
|
|
Could you actually show me how to use this while I am considering other options.
Have tried:
foreach (string sDir in Directory.GetDirectories("ip\\C$:\\"))
{
MessageBox.Show( sDir.ToString() );
}
|
|
|
|
|
I did: \\SERVER\C$. You could also use \\IP\C$. Don't use a colon ( . That's the admin share for a drive, which Windows NT establishes for each local drive automatically. And you don't need to call sDir.ToString because it's already a string.
foreach (string dir in Directory.GetDirectories("\\SERVER\C$"))
Console.WriteLine(dir);
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I'm writing a WinForms application that needs to update its user area on change of resolution by the user. I've overriden the WinProc method of my main form so that I can monitor the changes of the resolution and do what I need to do. Its body looks like this:
private const int WM_DISPLAYCHANGE = 0x007E; // this is the message notifying that the display resolution has been changed
protected override void WndProc(ref Message m)
{
base.WndProc (ref m);
if(m.Msg == WM_DISPLAYCHANGE)
{
MessageBox.Show("Width: " + Screen.PrimaryScreen.Bounds.Width + "\n" + "Height: " + Screen.PrimaryScreen.Bounds.Height);
}
}
The problem is that the Screen.PrimaryScreen.Bounds property doesn't work properly the first time the resolution is changed by the user after the application is started. It returns the previous resolution of the display. Here comes the strange part: all the following changes work fine.
I've tried using the Microsoft.Win32.SystemEvents.DisplaySettingsChanged event but the result is the same. Is there a way to get this right?
10x
K.
|
|
|
|
|
Works fine for me using SystemEvents.DisplaySettingsChanged . If something else is wrong, you could always use the Message.LParam split into low- and high-order bits that describe the new horizontal and vertical resolution, respectively. The new settings are packed and passed as the LParam property of the Message struct.
Also, you could save yourself a lot of typing like so:
MessageBox.Show(Screen.PrimaryScreen.Bounds.Size.ToString()); Just a suggestion.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
The thing with the low- and high- order bits works!!! I'm happy now Thanks a lot!
Btw, the DisplaySettingsChanged event handling shows always one and the same resloution - i.e. the resolution after the first change, which I find rather strange. Unfortunately, I cannot currently test the app at resolutions different from 800x600 and 1024x768 as I work on a 15'' LCD and this is all I get out of it
10x once again,
K.
|
|
|
|
|
What version of .NET are you using? I've looked at the IL for 1.0 and the SystemInformation and Screen classes actually handle the SystemEvents.DisplaySettingsChanged event and reset their cache. If, when you get the property next, the cache does not contain data the respective data is obtained, cached, and returned. Somethings definitely wrong there. The monitor would also have little to do with the resolution. You might check for newer drivers, although such a small LCD - and no offense meant - might only be possible to go to 1024x768.
One thing to keep in mind to make your code more portable from 32- to 64-bit processors: use the IntPtr.Size static property to get the byte-width of a native int (which is processor dependent). Shift bits accordingly.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hi,
I want to implement a class in C#, such that one instance of that object should be alive if there are threads using it. If no thread is using it, then delete the object.
So that the next time, any thread needs this class, it should again be created.
It could have been classic singleton, if it would have been alive throughout.
But the hitch is that i need to kill/delete the object when i determine that there is nobody else using it...
Is Locks/mutex is the way out along with reference count.
Could some body throw some light..
|
|
|
|
|
You could use a Singleton, combined with a Semaphore. Use a GetInstance() method and a ReleaseInstance() method. Increment/decrement the semaphore in these methods, and whenever your instance count reaches zero, release your internal singleton pointer and let the garbage collector have it.
Grim (aka Toby) MCDBA, MCSD, MCP+SB
|
|
|
|
|
You could use either .NET Remoting or a ContextBoundObject to do this as well. You can register a well-known object as a singleton in .NET Remoting with a lifetime of X number of some time unit. When no other objects reference that object, the .NET Remoting infrastructure disposes the remoting object.
With a ContextBoundObject and a custom proxy (using the ProxyAttribute - see the .NET Framework SDK documentation for more information and an example) so that you do the same thing without worrying about registering well-known objects.
Your custom proxy could, for example, catch the IConstructionCallMessage . In that case, you either create an instance of your object or return an existing instance. This object can still take advantage of the .NET Remoting infrastructure, such as the lifetime management services. See the ContextBoundObject.InitializeLifetimeService method documentation (inheritted from and defined by MarshalByRefObject ) in the .NET Framework SDK for more information.
Using a ContextBoundObject would probably be the easiest way to acheive what you want. This way, your client code can still new the class without knowing whether it receives a new or existing instance, and you can use AOP (Aspect-Oriented Programming - see Aspect-Oriented Programming / Aspect-Oriented Software Design[^] by Marc Clifton on this site).
You could use mutexes to solve this problem with a singleton pattern, but then your calling code is required to increment and decrement the reference count (like with COM, though ATL helps aleviate that). With an AOP approach, you don't need to worry about it. The .NET Remoting infrastructure takes care of this for you and you can always override certain methods and implement the right interfaces (like ILease and ISponsor ) to change this behavior if you want (or return null from InitializeLifetimeService to keep the object alive indefinitely). It's definitely worth checking out.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
You could use the WeakReference . You might find that it is easier than trying to manage reference counts. You can implement IDisposable as needed. The following code is thread-safe.
public sealed class Singleton
{
private static volatile WeakReference _Reference = new WeakReference(null);
private static Object _Lock = new Object();
<br>
public static Singleton GetInstance()
{
Singleton instance = _Reference.Target as Singleton;
<br>
if (instance == null)
{
lock(_Lock)
{
instance = _Reference.Target as Singleton;
if (instance == null)
{
instance = new Singleton();
_Reference = new WeakReference(instance);
}
}
}
<br>
return instance;
}
}
|
|
|
|
|
A question how referenses work and what not.
I have an object A that contains a reference to a B object.
Now I send A and B separately from my client to a server with an objectstream(J#, must use it even though it is annoying as hell) and stores A in an ArrayList and B in another ArrayList. Will the reference still be there?
So if I want to pick up B I can send an A object to the server and return A.getB() for example?
|
|
|
|
|
It depends on how they're transfered, deserialized, and hooked up. With .NET Remoting, this would be true so long as A and B are reference types. Unfortunately I can't seem to find any documentation on the ObjectStream class in the J# class library (basically mimics the JRE). The ObjectOutputStream and ObjectIntputStream documentation in the JRE do state that an object graph is serialized and deserialized, so what you expect should be the case. What I'm wondering is: why didn't you just try it and see? Assign some unique values to members of object A and B and assert those values on the other side.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thank you for the reply, the reason I did not try it is that it is someone in my group that is coding that part and we are doing some "theoretical" coding now and needs to make some design choises.
It turns out that he is using Java and will bind his server with our j# interface, I think that would work as he is not using anything after 1.1 I think.(We will later throw everything in a project in VS.NET)
The thing is that we have alot of references between objects and is wondering about the solution(I've asked something similar before). We tried to go away from our database thinking and have it like this:
Employee has a collection of resources.
Resources has one reference to an employee and one to a Project.
Project has a collection of resources.
This is that we want a client/server solution and how would you solve this problem in "real" life. We can do a simple program without any server or database but we want to make it as real as possible else it feels like we wont learn much.
Before we just had "foreign keys" (project id, employee id) in the resource, but I dont think that is good object oriented coding? But it makes it much easier to send objects to and from a server as we dont need a reference between the objects..but this is bad right?
Thank you for you help
(And what does Microsoft MVP stand for?, you seem to know alot about .NET)
|
|
|
|
|
|
Ok thanks, we will try to keep them even though we are having annoying problems with instanceof right now, that is on the level we are .
But will take your advice and start trying to send objects back and forth from the server/client.
|
|
|
|
|
The reference will still be there, but it will be broken. The reference is actually in IntPtr (pointer), which is really just a memory address. The only way the reference won't break is if object B happens to end up at the same memory address on the server (unlikely), or if you manually tear down the A object on one end, send the data, and manually reconstitute the A object on the other end, thus fixing the pointers.
Now, if A and B are both serializable, and you implement ISerializable in such a way as to serialize/deserialize B as a part of A, then it would be fairly simple to ensure that things are torn down and rebuilt properly.
Grim (aka Toby) MCDBA, MCSD, MCP+SB
|
|
|
|
|
Grimolfr wrote:
The reference is actually in IntPtr (pointer), which is really just a memory address.
Like .NET runtime serialization, the ObjectOutputStream and ObjectIntputStream hook-up the references again. Depending on how the data is formatted to be send across the wire, this has nothing to do with memory addresses. This is no different than what happens with .NET Remoting.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I shoulda known to stay out of it as soon as I saw J#.
And serialization [i]will[/i] serialize reference pointers instead of the objects they point to in some situations unless you explicitly override the serialization methods.
Grim (aka Toby) MCDBA, MCSD, MCP+SB
|
|
|
|
|
I'd be interested to know what situations those are. We've used both SOAP and binary formatting (runtime serialization) in our massive N-tier application I primarily architected and objects to which member fields reference (and what not) are serialized. This is especially true for SOAP where even a byte offset for a child object isn't possible.
In any case, the J# libraries work differently from the .NET FCL and to be honest, I'm really not sure about all that. It's basically a port of the JRE. I answered a question not long ago about java.util.Date . Someone for some reason thought that you could simply cast a DateTime to a Date . Not only wasn't that possible, but they use different epochs (which I remember from Java years and because of a couple recent projects interop'ing Java and .NET at the presentation layer that I developed a couple years ago).
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I've never run into it personally, but I read a forum message (on gotdotnet.com, IIRC) where a guy was serializing an object with SerializableAttribute, and not implementing ISerializable or providing a serialization constructor.
Problem was, the default serialization mechanism would serialize the function pointers assigned to any events. When he deserialized, the pointers were invalid, and caused all sorts of problems.
His actual issue in the post was that the NonSerializableAttribute applies to fields only, and not to events.
This was awhile ago, though. The default serialization functionality may have changed in 1.1 to not serialize event function pointers.
Grim (aka Toby) MCDBA, MCSD, MCP+SB
|
|
|
|
|
I see. That would make sense regarding delegates (event handlers). For fields, however, this shouldn't be a problem.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Is it possible to have a J# client and a Java server and send objects between them?
As it seems now our J# client only seems to handle all objects it gets from the Java server as Strings.
Just wondering if we must throw in the Server in the .NET environment or if we have made some other mistake.
|
|
|
|
|
I need a class that can be seen by multiple running exe's, but have only one instance running. The first program exe that opens will fire up the dll and all others after than will just use it.
I want to use this for a licensing situation. We have several front-end exe's that I want to do licensing for. The dll is going to communicate with a licensing server every few mins. If the server goes down, I want the dll to show a warning and close all exe's attached to it after a few mins.
I've never had to do anything like this before in c# and am looking for a couple of good ideas. I don't necessarily have to use the dll idea either. As long has I can attach a couple of exe's to the same instance of something in memory and catch a close event or message from it, it should work.
Another bad point is that all the exe’s aren’t in .net yet. Some are legacy vb6 still. I don’t know what problems this will entail, but the ideal solution would close them also.
I have evaluated several licensing packages and haven’t found one that will do what I want. The ones I can afford won’t and the ones that will do licensing per company are hugely expensive, so I think we have to roll our own.
If I could find a licensing package for under around 5K that would probably work also. We looked at flex LM but it’s ridiculously expensive. It would do the per company license scheme we want. (Company a buys 10 licenses, company b 100 etc. A can have 10 computers running my software at one instance in time (as many computers installed, just 10 running at one time), b 100 etc.)
Sorry for rambling here
If you need any other info or clarification let me know.
TIA
|
|
|
|