|
|
hey.. listen.. i did extensive readin on System.Net
IPGlobalProperties-> Provides information about the network connectivity of the local computer. .. i want to enum. neworks remember... AND i found some code that claims to enum. networks with System.DirectoryServices... .BUT i dont understand any of the code cuz... well its not commented at ALL!
it was originally in VB.NET... i got someone to port it to C# .. but the problme is i CAN:T check if it works on my PC!!.. cuz i dont hav networks.. COULD SOMEONE PLEASE TELL ME IF THE FOLLOWING CODE WORKS!/?
<br />
private void btnList_Click(object sender, EventArgs e) <br />
{<br />
DirectoryEntry entryRoot = new DirectoryEntry("WinNT://" + this.tbComputerName.Text.ToUpper(), "", "", AuthenticationTypes.None);<br />
<br />
DirectoryEntries memberEntries = entryRoot.Children;<br />
<br />
this.lvUsersGroups.SmallImageList = this.ImageList1;<br />
foreach (DirectoryEntry member in memberEntries)<br />
{<br />
if(member.SchemaClassName.Equals("User"))<br />
this.lvUsersGroups.Items.Add(member.Name, 0);<br />
<br />
if(member.SchemaClassName.Equals("Group"))<br />
this.lvUsersGroups.Items.Add(member.Name, 1);<br />
} <br />
}<br />
<br />
You will, of course, need to wire up btnList's Click event to call the above handler if you haven't already done so:<br />
<br />
this.btnList.Click += new System.EventHandler(this.btnList_Click);
heres where i got the original code - > http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=3213&lngWId=10[^]
PLEASE TELL ME IF EITHER ONE DOES THE JOB?
Thanx
Gideon
|
|
|
|
|
Hello
Easy Tiger!!
Well, yes it works, and shows my shared network printer if supplied with the computer name that's connected to the printer. Well done!!
I thought you wanted to enumerate connected PCs. What this code does is to enumerate shared folders on a Pc name that you supply!! What good is that for you? Otherwise from where do you get the this.tbComputerName??
As for the network problem. If you don't have more that one computer, you can download Microsoft's Virtual PC 2004 for free, and make a virtual network between your machine and the "Virtual PCs". This way you can test and modify you code step by step on your "Virtual network". Google for "Microsoft Virtual PC".
Regards ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
oh hey thats just what i needed..! virtual PC!.. .. thanx!
well .. yes.. i want to enum. pcs. .. before i started c# , i somehow figured out how to enum with the WNetOpenEum , and its companion API!... IN VB6 ... so do u think i should just go for enumerating with API , or can i do it in system.net or system.directoryservices... i got an offer to make booking application.. my boss has around 3-4 pcs..and the app. should basically just list the full path to all availiable pcs....
if theres no way with the .NET classes .. would u happen to know a tute for:
1. using simple API in C#
2. using the WNetOpenEnum in C#
Gideon
|
|
|
|
|
Hello
giddy_guitarist wrote: i got an offer to make booking application
Congratulations!
giddy_guitarist wrote: just list the full path to all availiable pcs....
All right!! Here is the code:
IPGlobalProperties MyIP = IPGlobalProperties.GetIPGlobalProperties();
string RemoteComputer = "";
foreach(TcpConnectionInformation Con in MyIP.GetActiveTcpConnections())
{
try { RemoteComputer = Dns.Resolve(Con.RemoteEndPoint.Address.ToString()).HostName; }
catch { }
if (RemoteComputer.Length == 0)
continue;
if (!listBox2.Items.Contains(RemoteComputer))
{
listBox2.Items.Add(RemoteComputer);
}
}
This should enum all tcp connections -including those on your LAN-. To identify those on the lan use there IP address. They shouild be similar, first 3 numbers are usually the same eg.
178.65.32.103
178.65.32.106
178.65.32.201
178.65.32.305
giddy_guitarist wrote: just list the full path to all availiable pcs....
Simply: @"\\" + RemoteComputer
giddy_guitarist wrote: using simple API in C#
You are talking about P/Invoke. There are tons of articles about this topic here in CP
Regards
|
|
|
|
|
|
Hi All,
I want to send fax for the invoice generated through my web application using a fax voice modem. I have tried to utilise the MS Extended Fax API but not much help is available for that. Can anyone suggest some third party API for the same or any other solution which can be utilised. Thanx in advance.
Regards
|
|
|
|
|
Please tell me how to set the visibility of label item under collections inStatusTool Strip control? Also how to access the label item with the help of EventArgs obbject? eg. e.????
|
|
|
|
|
Hello
statusStrip1.Items["Label Name"].Visible = true;
rasper wrote: Also how to access the label item with the help of EventArgs obbject?
What is your event handler??
Regards
|
|
|
|
|
Hello, all. I've gotten a lot of help off this forum in the past, and I appreciate it! I hope someone can help me out with this one.
I have a timer, and I want the Interval to be as small as possible (timer to run as fast as possible). However, when I set it to 1, the program actually runs slower than if I set it to a more realistic number (like 30 or 50). This is because I have a number of steps to take with each tick. If the timer were just waiting for the previous tick to finish, there would come a point at which smaller and smaller Intervals wouldn't change the speed of the timer. But, the action does, in fact, slow down more and more with small values. This tells me that the timer is skipping a tick if the previous tick hasn't finished (just a theory, mind you).
Is there a way I can make the program tell me when the Interval is too small? I want it to realize when it's not finishing the code in the tick handler fast enough.
Ideas, anyone?
-Daniel
Typing too fast fro my owngood
|
|
|
|
|
Hello
First I must say it's an interesting post you've made. Got my 5
To the issue. I thought of several solutions to this. The best thing I came up with is to test the time - or average time- of excution of your code. Maybe like this
Long FirstTick;
long BestInterval;
private void MyTickEventHandler(object sender, EventArgs e)
{
FirstTick = DateTime.Now.Ticks;
BestInterval = DateTime.Now.Ticks - FirstTick;
}
Well, I hope this works!!
Regards
|
|
|
|
|
I thought about it for a while, before I saw your reply. You're right, monitoring DateTime.Ticks is best for my situation. I decided to monitor DateTime.Now.Ticks, and keep track of the difference between how long an iteration is supposed to take, and how long it actually takes. If it was more than a certain threshold (one millisecond... I know, that's a lot), then I threw an exception. Then, instead of throwing an exception, I just increased the timer's interval. I've gotten it to run at 60 milliseconds per timer interval without a hitch.
I'll keep my checks in there, to monitor its progress with my changes (I intend to add a little more code per tick).
Thanks for the help!
-Daniel
Typing too fast fro my owngood
|
|
|
|
|
Hi there,
Which timer are you using? Windows based? the one which is in toolbar?
Did you try System.Timers.Timer? It uses Threadpool if interval is smaller than the processing time of Elapsed event handler.
Hope this might help.
|
|
|
|
|
I'm using System.Windows.Forms.Timer.
I don't have a "toolbar" because I'm using Notepad and csc.exe (it's the manly way to program, although I revert to VS2k5 for hairy problems).
-- modified at 20:48 Friday 25th August, 2006
-Daniel
Typing too fast fro my owngood
|
|
|
|
|
And probably OS dependent as well. I would imagine the best way would be to profile the method in the tick timer. The profiler may be part of the CLR (don't know never checked) then you can dynamically check the profile to set the timer tick.
On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Charles Babbage
|
|
|
|
|
I don't know what it means to "profile" a method. I suspect it's a little deeper than what is needed for this program I'm working on. However, (pardon the pun) thanks for the pointer!
-Daniel
Typing too fast fro my owngood
|
|
|
|
|
Just a small question beside your actual problem:
If you really want to call some function/do some task repeatedly as fast as it is possible why do you use a timer (and not some kind of loop - probably in another thread)?
|
|
|
|
|
Why have I chosen a System.Windows.Forms.Timer? Because, I've been told by a CS PHD at my local University, multithreading is not advantageous if you're just trying to do something faster. The CPU can really only process information at a certain speed, and making two threads won't make it faster. I understand that multiple threads is handy when you want things to run independent of each other, but it's not for making a linear sequence of actions run faster. Besides, it's just a game.
On a side note, considering there are multiple entities in the game that are meant to run as autonomously as can be faked, I did consider making each entity run in its own thread. However, I decided against it, just to keep things simple.
-Daniel
Typing too fast fro my owngood
|
|
|
|
|
System.Windows.Forms.Timer is based on the WM_TIMER message with all of its associated limitations. Significantly, it is the lowest priority event of all, after painting the window. Any other message handlers which take a significant time will hold up the processing of the timer event. The system will post another timer event after the time has elapsed after the previous one was processed. The resolution of the timers is the same as the system timer tick, which on Windows XP is 15ms. On Windows 98 it is 55ms IIRC.
I don't really get on with System.Threading.Timer. Its behaviour is to fire events on the threadpool, and it has no locking to prevent the events being fired concurrently - if your first handler hasn't completed, the thread pool will (if threads are available) run it again, concurrently, on another thread. I believe the timer resolution is the same as for System.Windows.Forms.Timer. Because it runs on the threadpool, it's unsafe to run any GUI code in the handler.
System.Timers.Timer is based on System.Threading.Timer. If you set the SynchronizingObject property, the callbacks are fired synchronously on the correct thread for that object, so the limitations above don't apply - it is safe to run GUI code, and callbacks cannot occur concurrently.
For the resolution you're after, you probably need a multimedia timer. This actually tweaks the system timer resolution. See this article[^] for a C# wrapper around the multimedia timer APIs. I haven't tried this code out, so I can't make any claims for it.
|
|
|
|
|
<sincer>Thank you for the interesting insight!</sincere>
You bring up an interesting point. However, this program (a simple game) depends on the user seeing what's being painted so they can react properly. Thus, I prefer that painting have a slightly higher priority than the processing between painting.
Now that I've had time to sit on my code over the past day or two, I've realized that it's alright if the System.Windows.Forms.Timer skips a tick (if the timer is running faster than the code), because of the way I'm tracking movement. There are entities that move on the screen so-many pixels per second, and if a timer tick is skipped, it's made up in the next tick (by how I'm passing info around), so on each repaint the entities have moved the proper amount of distance.
Really, to be honest, the whole reason I wanted it to run as fast as possible is that I want it to repaint as fast as possible, so that the motion will appear as smooth as possible. I just didn't want choppy motion.
On a side note, I was going to ask what you mean by the "system timer" having a resolution of "15ms"? Is that milliseconds or microseconds? I ask because DateTime.Now.Ticks tells you a value down to the nearest 100 nanoseconds, which is a lot more accurate than "15ms," no matter what you're signifying with that 'm'. I added some code the other day that uses DateTime.Now.Ticks to measure how accurate System.Windows.Forms.Timer is running in my program. I do admit that System.Windows.Forms.Timer is not very accurate (the worst I saw was a disparity of .7 milliseconds), but it's good enough for what I need.
My original question was for a way to make the program tell me when the System.Windows.Forms.Timer.Interval was too small, and I made DateTime.Now.Ticks tell me that (by measuring how long a tick took compared with how long it should have taken).
I appreciate all the help, everyone! I'll just keep tweaking what I have. After all, I still have some stupid trig to get straight (things keep going in weird directions).
-Daniel
Typing too fast fro my owngood
|
|
|
|
|
The system timer has a resolution, typically, of 15 milliseconds. The actual value depends on the exact hardware you have. The physical timer periodically interrupts a processor, which the OS handles to fire off timer events, and to decide whether to reschedule the CPUs if there are multiple threads that can run.
The operating system counts time in 100ns intervals, it's true. However, it simply adds a fixed value to the 'current wall-clock time' variable every time a timer interrupt occurs. That value can be altered with the SetSystemTimeAdjustment API, and it's used to compensate for the slight inaccuracies that occur with the actual versus theoretical run rate of the clock, and slight issues surrounding responsiveness to the clock interrupt.
The divergence you're seeing between DateTime.Now.Ticks (which is the system clock time) and the timer interval is probably the latency in having the timer fire. If you want a time stamp with more resolution, see the QueryPerformanceCounter API, which is generally based on a processor performance monitoring register. However, on some processors this can be unpredictable as it is directly related to the core's running clock speed, and power management can vary the clock speed, so the counter doesn't count at a constant rate!
The physical hardware timer circuit is programmable. To support multimedia applications that require a better resolution for their timers, the OS can reprogram it for more frequent interrupts, which it does if an application uses the multimedia timer APIs. When all applications free their multimedia timers, the OS goes back to the default timer interval. Presumably this is to reduce the overhead in thread time accounting and thread dispatching.
|
|
|
|
|
I'm replying here because, although I got the notification message, your other post didn't show up on the forum!
Heritos Gger wrote: Don't get me wrong, I'm not arguing with you. You obviously know a lot more about it than me, I admit.
However, I still don't understand how you would say that the "system timer" has a resolution of 15 milliseconds and the "system clock time" has a resolution of 100ns. System.Windows.Forms.Timer has a resolution of one millisecond (better than 15). Are these three different timers we're talking about?(100ns,1ms,15ms resolution)
I was under the impression that there's one clock in the CPU, and everything gets chronological measurements from that (although, now that I've typed that, it sounds way too simple for CPU guts).
Thank you for your patience with me!
I need to point you to Raymond Chen's blog post, "Precision is not the same thing as accuracy"[^].
The system's clock measurements are based entirely around the Programmable Interval Timer component. This component, on x86/x64 computers, dates back to the original IBM PC, in which it was an Intel 8253 chip. In modern computers it's a circuit somewhere in one of the chipset chips (on my Intel 850-based P4 system it's hanging off the Low-Pin-Count controller, according to Device Manager where it appears as 'System timer' - this is the successor of the antique ISA bus, for devices that aren't expected to handle the complexities of PCI!)
(I've seen documentation on Wikipedia that this interval timer function is actually now performed by the Local APIC, which is a circuit of the processor which manages interrupts, so this may not be completely accurate, if your system also has an I/O APIC and Windows is using it, which most modern systems do. This would explain why the 'System timer' is shown as being in power state D3, which is the state with highest power savings and effectively means 'off'.)
Anyway, this timer component is programmed to interrupt the processor on a regular basis, by default every 15.625ms on my system. (You can find out the clock resolution using the ClockRes[^] utility.) Why the odd number? It's actually 1/64th of a second.
The SetTimer API (and hence System.Windows.Forms.Timer) accepts an interval specified in milliseconds, GetTickCount and GetSystemTime offer a multiple of milliseconds as their result, and GetSystemTimeAsFileTime (hence DateTime.Now.Ticks) offers multiples of 100ns. However, none of these APIs can offer this actual resolution. They're all tied to the programmable interval timer circuit's tick rate.
The system also has a real-time clock circuit introduced in the IBM AT, but that is useless for actual timekeeping since it requires a total of 6 I/O bus write/I/O bus read pairs to retrieve the actual time, and it only counts in 1 second intervals anyway. The operating system only reads from it at startup and writes to it when adjusting the clock (SetSystemTime or SetLocalTime, not every tick from the PIT circuit!) and on shutdown.
Why does the FILETIME structure (hence Ticks) have such an absurdly high resolution? I assume it's because NT was meant to be, and was, portable to other architectures which didn't have such lame timer capabilities. You'd need at least microsecond resolution with that default clock rate; if you only had millisecond resolution and added 15ms every tick, your clock would be 4% slow, losing nearly 2 1/2 minutes every hour. If the clock is varied down to approx 1ms (which would be implemented on the PIT as 1/1024 seconds, 976.5625us) you're starting to hit the actual resolution of the structure. 62.5ns will be lost every time the timer ticks in this case, but that's less than one part per million, far better than the hardware can actually do.
-- modified at 17:17 Sunday 27th August, 2006 (messed up closing format tag)
|
|
|
|
|
The reason I replied off the forum was because I didn't want to task others' patience on what is turning out to be a detailed explanation of timers. It's venturing a little from C#.
From what you've explained, it sounds like they need to come up with a better way to track time. Perhaps they could use current sub-micron semiconductor manufacturing technology to make a quartz crystal that ocillated reliably (although I realize it would have to be a lot faster than those in watches).
My original idea was finding out exactly how much time a process took from start to finish, so that I could repeat it with as little idle time between finish and start as possible.
The more I work on this program (I've added more to its iterative processes), the more time I have to add to myTimer.Interval. I guess as long as the process doesn't take more than 15 fps, I should be fine (because, after all, it's just a stupid game... a game I get the feeling I'm making more complicated that it needs to be).
Thanks for the information!
-Daniel
Typing too fast fro my owngood
|
|
|
|
|
Does anyone know what format string I need to pass into the DateTime ToString() method to display the current date and time as 08/25/2006 14:48? Thanks.
|
|
|
|
|
See the "Custom date formatting" section here[^].
/ravi
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
..... i still have to complete the Advanced section in my book(wrox beginnin C# 05) which of course covers a little on net clasess.. i'll get back to this after that i . 
