|
Shucks. Thanks for the information.
#include "witty_sig.h"
|
|
|
|
|
I have a form that contains 200 textboxes in a table format, all named the same except with a number appended (i.e tbName1-tbName200). If I want to process these textboxes in a loop to capture the text values, how should I do this? Do I look for all of the components in the form and examine each component to see if it matches the name I'm looking for; seems to me that this is a difficult way to find the actual textbox object.
--Mike
|
|
|
|
|
You could add a Panel or GroupBox behind the TextBoxes, then just iterate through the control in the Panel or GroupBox.
The following is just an shove in the right direction, I believe this approach will work.
private void CycleTextBoxes()
{
foreach( Control ctrl in gbTextBoxGroupBox.Controls)
{
TextBox tbTemp = (TextBox)ctrl;
if(tbTemp!=null)
{
}
}
}
|
|
|
|
|
You will get an exception. Instead, use TextBox tbTemp = ctrl as TextBox; The as keyword performs a safe cast, returning null if the cast isn't valid instead of throwing an InvalidCastException. If that cast wasn't valid, only then when tbTemp be null.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
...
...
...
public class INI
{
public INI(string Path)
{
INIPath = Path;
}
public string INIPath=null;
[DllImport("kernel32")]
private static extern long WritePrivateProfileString(string section,string key,string val,string filePath);
[DllImport("kernel32")]
private static extern int GetPrivateProfileString(string section,string key,string def,StringBuilder retVal,int size,string filePath);
[DllImport("kernel32")]
private static extern int WritePrivateProfileSection(string section,string Entries,string filePath);
public void ClearSection(string SectionName)
{
WritePrivateProfileSection(SectionName,"",this.INIPath);
}
public void WriteINI(string Section,string Key,string Value)
{
WritePrivateProfileString(Section,Key,Value,this.INIPath);
}
public string GetINI(string Section,string Key,string DefaultValue)
{
StringBuilder temp = new StringBuilder(255);
int i = GetPrivateProfileString(Section,Key,"",temp,255,this.INIPath);
if(i==0 && DefaultValue!="NOADD")
{
WriteINI(Section,Key,DefaultValue);
return DefaultValue;
}
if(i==0 && DefaultValue=="NOADD")
return "NOADD";
return temp.ToString();
}
}
|
|
|
|
|
Try to use this function
private void avoidTextboxes()
{
FieldInfo[] fields = this.GetType().GetFields(BindingFlags.Instance | BindingFlags.NonPublic);
TextBox _btn;
foreach (FieldInfo fi in fields){
if (null != (_btn = fi.GetValue(this) as TextBox))
{
_btn.Text += " was modified";
}
}
}
xedom developers team
|
|
|
|
|
Thanks to you all for your time and suggestions, I'll try some of them out. Since I'm processing an input form of 21 columns x 25 rows, for each textbox name, if I loop through all of controls to find the textbox's text value, I'll potentially be doing this hundreds of times for each one.
So what I may use is a HashTable to store the TextBox's name and the TextBox Object so I can look for the key and then if it's there, just get the TextBox object and it's associated Text value. Any thoughts on this?
--Mike
|
|
|
|
|
Hi Everyone,
Is it possible to create a dotNet MDI app (C#) and use pinvoke to
create win32 client forms? This would mean using the CreateWindowEx
function and possibly sending over the dotNet parent Handle. If you
can do this, what steps should I take and watch out for? For example,
do I need to send over the HINSTANCE of the app and/or do I need to
set the MdiParent to the win32 child. Lots of questions here. Any
help would be totally awesome!
Cheers guys,
DrD.
|
|
|
|
|
Why on earth would you want to? The Form class is a wrapper for the Win32 Window class to begin with, so your already using the Win32 "Form" class.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Basically I have an existing program that pumps out OpenGL graphics to a win32 window. This window is created using CreateWindowEx. I now want to put a dotNet front to it and make it a client window of dotNet MDI. It sounds simple enough but I'm not sure how to set this up properly. Any ideas?
|
|
|
|
|
I've never even thought of attempting something like this. Can you get the OpenGL library to draw it's contents on a device context that you specify?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Ok, after tinkering around I've solved the problem. Basically I used interop to get down into win32 and used CreateWindowEx. At this stage I did not create a MDI child window but created a normal window. Once created (but before shown) I called "SetParent" and made this new window point to the dotNet main frame. I passed in the dotNet MDI frame handle to my win32 code dll. This worked a treat and I'm happy with the result. However, in doing this you will need to manage resize issues etc yourselves eg) using CreateWindowRect and the like.
Just to note, before I stumbled onto this I was trying to create a MDI child window using CreateWindowEx and it wasn't working at all. I guess this was due to some compatibility problem between dotNet/win32. Anyone else know why -or- have got it working like this?
Cheers,
SPM
|
|
|
|
|
i am a begineer in c#,and am not getting exact technical terms to explain my problem, though i shall try my best.i have developed a program which takes values from a textbox. its obvious that when i run the program for second time the previously entered values through textbox will get wiped out & textbox will ask for new values. how do i avoid this? how do i make program to run as may times as i want on the values i entered for first time when i ran the program? & only take new values when i change the contents of textbox & continue with this values for any number of times i run the program.
|
|
|
|
|
You need to write the initially entered value to a file or registry someplace. The most commplace is either an INI file or the Registry.
|
|
|
|
|
Not for a .NET application. It's recommended you don't use the registry (for deployment reasons), and even more recommended you don't use INI files (the flat structure is very problematic in this day and age).
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
then what *do* you use?
-------------------------------------------------------
ithium is the best.
'Science without religion is lame, religion without science is blind.' --Albert Einstein
'The pioneers of a warless world are the youth who refuse military service.' --Albert Einstein
|
|
|
|
|
I posted it as a direct reply to the parent thread.
.config files are best to target, although writing to them can be dangerous if you don't take errors into account. The registry is an option, but is not recommended because of deployment issues, such as XCOPY deployment.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
It's a common practice to actually serialize your controls using XML Serialization to a file. When you instantiate these controls you read your values from that file again.
The biggest problem with serialization, though, is that your controls are actually deserialized in their entirety. So the best approach for you is to use an XmlDocument or XmlTextWriter to write these values to an XML file, and read them back in with XmlDocument or XmlTextReader. Using XML files is easy in .NET, and there are actually lots of articles here on CodeProject about just what you're asking.
You could use the registry (it's strongly recommended you don't use INI files, which are not supported by the .NET FCL (framework class library)), but it's not recommended for deployment reasons. This isn't always such a bad thing if you don't require initial registry values, though. In your case, that would be true.
So whether you use an XML file or the registry, just save your text when the form is closed and read them back in when you open your form.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I am in a migration project of conversion of COM components written in VC ++ to either Managed VC++ or C#.
Can anyone suggest me how to proceed with this.
Client wants to the development team to use some migration tool and convert it and after that rectify some minor errors and modifications.
I tried open the VC++ project in the MS Visual Studio.Net, but when I tried to build, it didn't worked out giving multiple errors for the header files.
Please suggest as I need to give some solution at the earliest.
|
|
|
|
|
If you plan on supporting the legacy COM clients, you'll need to understand COM interop in .NET. This means following COM guidelines, like versioning interface names, not using auto-generated class interfaces (despite the fact that most Microsoft examples do), etc.
Start by reading Interoperating with Unmanaged Code[^] in the .NET Framework SDK. There's lots of books out there on this, too.
If you don't care about supporting legacy clients, then it's not really a problem. Design your object model anew taking advantage of the rich features in the .NET FCL (and other third-party libraries if you like) like runtime serialization, XML serialization, .NET Remoting, etc. What you need depends on your requirements, so no one in this forum could really help there (a forum is a good place for specific questions).
As far as the errors in VS.NET regarding headers, all I can tell you is to go through and resolve them. Make sure you installed the Platform SDK when you installed VS.NET, or download it from http://msdn.microsoft.com/platformsdk[^] and be sure to register the paths with VS.NET (though I usually go back and put them all in environment variables so I can easily use command line tools and VS.NET uses the env vars by default).
If you have questions about specific errors when trying to compile your old VC++ projects in VS.NET, I recommend you ask in the VC++ forum since this forum is for C# specifically.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hi,
I've been lookin at using IO Completion Ports (through Socket.BeginXxx) within my network application (instead of using a thread for each client connection), but my findings are discouraging.
I was under the impression that IO Completion Ports improve performance and are a scalable solution to client/server connections. For this, I was expecting any benchmarks between using IO Completion Ports and using a thread for each client connection to be in favour ot IO Completion Ports. My tests however, indicate otherwise.
My tests are very simple, client sends a message and server receives it. No other action takes place, it is as simple as that. Here is the interesting part of the code:
Server
private void BytesReceived(IAsyncResult ar) {
SocketAndBuffer socketAndBuffer = (SocketAndBuffer) ar.AsyncState;
int noOfBytesReceived = socketAndBuffer.Socket.EndReceive(ar);
if (noOfBytesReceived != 0) {
socketAndBuffer.Socket.BeginReceive(socketAndBuffer.Buffer, 0,
socketAndBuffer.Buffer.Length, SocketFlags.None, new AsyncCallback
(this.BytesReceived), socketAndBuffer);
}
}
Client
while (true) {
socket.Send(bytesToSend, 0, bytesToSend.Length, SocketFlags.None);
Thread.Sleep(10);
}
I run two variations of the test, one with the code as it appears above and the other (more brute force) with the Thread.Sleep(10) commented out. Below are the results:
10ms wait between sends, using completion ports, 40 connections
----------------------------------------------------------------
Processor Queue Length: 42.700 average, 44.000 max
Processor Time: 0.501 average, 5.000 max
Context Switches/sec: 16394.070 average, 16486.271 max
10ms wait between sends, using threads, 40 connections
------------------------------------------------------
Processor Queue Length: 42.817 average, 46.000 max
Processor Time: 0.167 average, 1.000 max
Context Switches/sec: 16343.139 average, 16475.683 max
No wait between sends, using completion ports, 1 connection
-----------------------------------------------------------
Processor Queue Length: 6.098 average, 9.000 max
Processor Time: 100 average, 100 max
Context Switches/sec: 13842.128 average, 14126.729 max
No wait between sends, using completion ports, 10 connections
-------------------------------------------------------------
Processor Queue Length: 6.475 average, 11.000 max
Processor Time: 100 average, 100 max
Context Switches/Sec: 48305.052 average, 49553.108 max
No wait between sends, using threads, 1 connection
--------------------------------------------------
Processor Queue Length: 6.525 average, 11.000 max
Processor Time: 100 average, 100 max
Context Switches/Sec: 52214.525 average, 53155.988 max
No wait between sends, using threads, 10 connection
---------------------------------------------------
couldn't gather statistics, CPU was getting hammered
In the case of 10ms wait between sends and 40 connections, using
threads instead of completion ports results in 3 times less cpu util
on average, 5 times less peak cpu util and on par context switches and
processor queue length.
In the case of no wait between sends and 1 connection, using threads
results in an 8% more context-switches and everything else on par.
It was not possible to gather statistics for 10 connections using
threads and no waiting between sends, but I think that's because all
the threads run at a priority level of Normal, hogging the CPU whilst
the completion ports have a threshold. No matter how many connections
I created to the server using completion ports, cpu util would remain
the same, it just had more requests queuing up.
What are your thoughts on this?
Thank you in advance
Angelos Petropoulos
|
|
|
|
|
IOCP's will give you better performance and scalability. I don't see any problems with the results of your tests. In fact, I'd say the tests with no send wait proves that IOCP's are performing better. The tests with a send wait aren't stressing the server app enough to fully realize the benefits of IOCP's. Keeping incrementally increasing the number of connections during the test as well. Hundreds or even thousands of connections on a sufficiently fast box isn't out of the question.
Also, there's no need to create a new AsyncCallback everytime. Just create one and reuse it. I don't think it will make a dramatic difference, but every little bit helps.
|
|
|
|
|
Well, in the case of no waits between sends I think the only reason IOCP are working better is because they have a queue and a threshold. All that happens is that requests are qeueing up and qeueing up. I believe this to be true because there was no difference in CPU util between 1 and 10 client connections.
In the thread server though, all the threads have a priority of Normal and no threshold, which means that if you ask them to work as hard as to hog the whole system they will. I can see this as a clear advantage of IOCP (having the threshold etc.), but I can't see any evidence towards better performance when using IOCP.
I just do not understand why individual threads would work more efficiently (less CPU util and same amount of context switches per second) in the scenarios of 40 or even 100 client connections. Is there some sort of dependance between the benefits of using IOCP and the number of connections? By that I mean, does the number of connections have to be above a certain number of the benefits of IOCP to be apparent? In which case, since my application won't deal with more than 100 connections, I am better off using individual threads for each connection.
In any case, I will take your advice and change the line that creates a new call back all the time (oops). I will also run some more tests. If I find something interesting I will post my results here.
Thank you for your reply, not many people want to touch this subject. I've posted in the newsgroups, in other forums as well and you are only the second person to reply. Much appriciated.
Regards,
Angelos
|
|
|
|
|
Angelos Petropoulos wrote:
Is there some sort of dependance between the benefits of using IOCP and the number of connections? By that I mean, does the number of connections have to be above a certain number of the benefits of IOCP to be apparent?
Well, not really. But, the thread pool does contain up to 25 threads* so the difference in performance between threads and IOCP's would be marginal with 25 connections, although I think you should still be better of with IOCP's. As the number of connections increases you should also see a bigger difference in performance favoring IOCP's.
Angelos Petropoulos wrote:
In which case, since my application won't deal with more than 100 connections, I am better off using individual threads for each connection.
Yeah, this is probably true since using asynchronous operations is more complex. There's more synchronization issues to worry about, more testing, etc. But then again, having 100 threads inside a process isn't the norm either.
Angelos Petropoulos wrote:
Thank you for your reply, not many people want to touch this subject. I've posted in the newsgroups, in other forums as well and you are only the second person to reply. Much appriciated.
Yeah, I just found your thread in microsoft.public.dotnet.framework.performance. Please report back here if you discover anything. You're right though, there aren't very many people who even know what we're talking about 
*Actually there are 25 per processor.
|
|
|
|
|
Actually, and I only found this out myself recently, worker threads and IOCP threads are different. The .NET Threadpool has both, 25 of the former and 1000 of the later. You can tell by just looking at the signature of the following method found in the class Threadpool:
public static void GetAvailableThreads(ref Int32 workerThreads, ref Int32 completionPortThreads);
I will be doing some more tests soon, because I want to get to the bottom of this once and for all. I will post my findings here. Shouldn't take long ...
Regards,
Angelos Petropoulos
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
