|
If the variable is only allowed to hold certain set of values, I wouldn't use string at all... An enum is the way to go. Enums can be converted to string easily and you can also parse a string to get the corresponding enum value.
If, for some reason you really need to use a string, there are several ways to validate it. Using a regular expression might be a good way to do it...
|
|
|
|
|
Yes an Enum should do the trick.
Jack Sparrow
--------------------------------------
Defeat is not the worst of failures. Not to have tried is the true failure.
|
|
|
|
|
To add to that, have a look atTips: Human readable strings for enum elements[^] which will let you use "In-Progress" as the string for the enum (normally you can't as enum elements must conform to normal C# variable name rules)
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
|
Hi all,
I am developing a winform application.This application has several (approx. 45) windows with custom rendering on it.
I am also using a third party tool for docking and undocking these windows.
When I play with all these windows (like docking undocking and moving them from thier location etc) very rarely I face this issue of an 'Application.OnThreadException'.
The custom rendering of all windows is heavy process.
Following A) is Exception and B) is the Stack trace I got once the exception has occured.
This issue is very hard to reproduce but it is there for sure.
Could you please guide me regarding any possible reason for the same?
Thanks in advance!
A) ---Exception Message ---
Object reference not set to an instance of an object.
B) ----Stack Trace---
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.OnThreadException(System.Exception t) + 0x8b bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProcException(System.Exception e) + 0x16 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnThreadException(System.Exception e) + 0xc bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg = 562, System.IntPtr wparam, System.IntPtr lparam) + 0x72 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0x232 (WM_EXITSIZEMOVE) hwnd=0xa0cbc wparam=0x0 lparam=0x0 result=0x0}) + 0x130 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes
Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.NotifyNativeWindow.WndProc(ref System.Windows.Forms.Message m = {msg=0x232 (WM_EXITSIZEMOVE) hwnd=0xa0cbc wparam=0x0 lparam=0x0 result=0x0}) + 0xb3 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 562, System.IntPtr wparam, System.IntPtr lparam) + 0x57 bytes
[Native to Managed Transition]
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0x112 (WM_SYSCOMMAND) hwnd=0xa0cbc wparam=0xf012 lparam=0x10f0494 result=0x0}) + 0x93 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.DefWndProc(ref System.Windows.Forms.Message m) + 0x89 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x40a bytes
System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.WndProc(ref System.Windows.Forms.Message m) + 0x2a bytes
System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.WndProc(ref System.Windows.Forms.Message m) + 0x10 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.WmSysCommand(ref System.Windows.Forms.Message m) + 0x70 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.WndProc(ref System.Windows.Forms.Message m) + 0x1ec bytes
Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.FloatingForm.WndProc(ref System.Windows.Forms.Message msg = {msg=0x112 (WM_SYSCOMMAND) hwnd=0xa0cbc wparam=0xf012 lparam=0x10f0494 result=0x0}) + 0x22b5 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) + 0x10 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x31 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg = 274, System.IntPtr wparam, System.IntPtr lparam) + 0x5a bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0x112 (WM_SYSCOMMAND) hwnd=0xa0cbc wparam=0xf012 lparam=0x10f0494 result=0x0}) + 0x130 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes
Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.NotifyNativeWindow.WndProc(ref System.Windows.Forms.Message m = {msg=0x112 (WM_SYSCOMMAND) hwnd=0xa0cbc wparam=0xf012 lparam=0x10f0494 result=0x0}) + 0xb3 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 274, System.IntPtr wparam, System.IntPtr lparam) + 0x57 bytes
[Native to Managed Transition]
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0xa1 (WM_NCLBUTTONDOWN) hwnd=0xa0cbc wparam=0x2 lparam=0x10f0494 result=0x0}) + 0x93 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.DefWndProc(ref System.Windows.Forms.Message m) + 0x89 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) + 0x10e bytes
System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.WndProc(ref System.Windows.Forms.Message m) + 0x2a bytes
System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.WndProc(ref System.Windows.Forms.Message m) + 0x10 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.WmNcButtonDown(ref System.Windows.Forms.Message m) + 0x29 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form.WndProc(ref System.Windows.Forms.Message m) + 0x1de bytes
Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.FloatingForm.WndProc(ref System.Windows.Forms.Message msg = {msg=0xa1 (WM_NCLBUTTONDOWN) hwnd=0xa0cbc wparam=0x2 lparam=0x10f0494 result=0x0}) + 0x1f53 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) + 0x10 bytes
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x31 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg = 161, System.IntPtr wparam, System.IntPtr lparam) + 0x5a bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0xa1 (WM_NCLBUTTONDOWN) hwnd=0xa0cbc wparam=0x2 lparam=0x10f0494 result=0x0}) + 0x130 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes
Syncfusion.Tools.Windows.dll!Syncfusion.Windows.Forms.Tools.NotifyNativeWindow.WndProc(ref System.Windows.Forms.Message m = {msg=0xa1 (WM_NCLBUTTONDOWN) hwnd=0xa0cbc wparam=0x2 lparam=0x10f0494 result=0x0}) + 0xb3 bytes
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 161, System.IntPtr wparam, System.IntPtr lparam) + 0x57 bytes
[Native to Managed Transition]
[Managed to Native Transition]
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int dwComponentID, int reason = -1, int pvLoopData = 0) + 0x24e bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason = -1, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.ApplicationContext}) + 0x177 bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) + 0x61 bytes
System.Windows.Forms.dll!System.Windows.Forms.Application.Run(System.Windows.Forms.Form mainForm) + 0x31 bytes
|
|
|
|
|
srng.net wrote: Could you please guide me regarding any possible reason for the same?
The reason is quite simple, as noted in the exception message you have an uninitialised object reference. The cause, however, is far more difficult to determine. You need to look at the code to try and see what references are being made/used around the point of the exception. Perhaps add some debug code or link to your program with the debugger when the exception occurs.
Since you are using a third psrty tool you may also like to talk to the suppliers to see if it could be an issue with their code.
It's time for a new signature.
|
|
|
|
|
Hi Richard,
Thanks for the reply.
The reason is not the one which is seen at upper level.(Object not set to an instance of an object)
This is caused due to Application.ThreadContext.OnThreadException.
Here I am not able to get the reason for Application.ThreadContext.OnThreadException.
If you see the detailed log, there we can ,after NativeWindow.Callback this exception is raised inside System.Windows.Forms.dll.
Why the dll has raised an exception?
My point of view, This can not be becasue of third party tool. Reason : Again we can look into the StackTrace where the exception is raised by System.Windows.forms.dll and third party tool is just passing comand to WM_ExitSizeMove and leaving the handle to windows.
I need to know Why this exception is raised.
|
|
|
|
|
Since this appears to be somewhat random I can only repeat my previous suggestion that you add debug code or trap the application with he debugger when the exception occurs. Without understanding your code or the third party library it is impossible to make any other suggestions.
It's time for a new signature.
|
|
|
|
|
srng.net wrote: My point of view, This can not be becasue of third party tool. Reason : Again we can look into the StackTrace where the exception is raised by System.Windows.forms.dll and third party tool is just passing comand to WM_ExitSizeMove and leaving the handle to windows.
The problem can very well be inside the third party library, or how you're using it. If your updating controls from anything other than the UI thread, behavior is unpredictable. It should throw an exception about the cross-thread boundry call, but that's not guaranteed to be thrown in all cases.
I'd get with SyncFusion about this and explain what the circumstances are that threw the exception, how the control is being used, ...
|
|
|
|
|
Dear all,
This is my situation:
I try to create text file by using below code:
using (FileStream fs = File.Create(path)){};
It runs ok at debug mode, file is create at [path].
But nothing happens at release mode.
What wrong with this code? Pls. explain for me if you know.
|
|
|
|
|
you should put that in a try-catch and look at the Exception.ToString().
what is the exact content of path?
does the path exist? (if relative, it could be different in release vs debug)
Which Windows edition?
|
|
|
|
|
Thank for your reply.
About your question, I answer as below:
- I also put the try-catch & look for Exception, but there is no exception.
- The path is absolute path: C:\Program Files\MyFolder and it is existed.
- I run in Window XP, VisualStudio 2003.
|
|
|
|
|
If you are trying to write to Program Files it could be a permissions issue. I would try another path that is definately going to accessible such as:
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)
To get the path you're using ath the moment I would do it this way:
string folderPath = Path.Combine(
Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles), "MyFolder");
I doubt that is related to your problem but may avoid problems in future.
|
|
|
|
|
ndkit wrote: Window XP
That is OK, and will not add unexpected limitations to what you can and can't do.
ndkit wrote: VisualStudio 2003
So you are using .NET 1.1?
I haven't used that for many years now, and I never will target it again. By all means, consider switching to .NET 2.0 (or higher). I'm not saying your problem is directly related, however 2.0 is much better than earlier versions, both in quality and functionality.
If you don't have VS 2005/2008/2010 available, you might try using VS 2010 C# Express Edition, which is free and can be downloaded here[^].
|
|
|
|
|
I have a web service that recieves calls from a number of clients (600 and growing). This calls a 3rd party web service to return some image data, which is then sent to the client.
If i spam the 3rd party service with several calls at once (around 20+), it grinds to a halt, and takes over 2 seconds per call to return, when it normally takes 0.3 seconds on a single call.
I noticed that if i throttle the calls (added a sleep of 500ms between each web request), the 3rd party runs fine.
The question is, whats the best way/how can i implement a throttling system in my code, so if i receive several calls on different threads, i dont send them all at once, but que them up, so the 3rd party server has time to respond.
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
A throttle is generally a looping background thread, combined with a queue and a signaling mechanism... Here's one way to do it (Pseudocode):
public SendItem()
{
Add request to queue
Send a new data signal (Perhaps a System.Threading.EventWaitHandle)
}
private Throttle() (Running on background thread)
{
Loop indefinitely
{
If queue is empty
Wait for signal
Else
{
Process item from queue
Wait X milliseconds
}
}
}
|
|
|
|
|
Below is the code i've done from your example.
The only bit i am unsure about is the waithandle. I know what/how to use them, but am unsure how it works in this scenario. Why would i want to hold the thread at a point?, is it just to save cpu cycles so it doesnt keep checking if the queue is empty?
public void AddImageRequestToQueue(string isbn)
{
Contract.Requires(!string.IsNullOrEmpty(isbn));
lock (_queuePadLock)
{
_imageRequests.Enqueue(isbn);
}
}
private void ProcessImageQueue()
{
do
{
if (_imageRequests.Count > 0)
{
string isbn = string.Empty;
lock (_queuePadLock)
{
isbn = _imageRequests.Dequeue();
}
IImageResult imageResult = GetImage(isbn, ImageSize.Small);
OnProcessImageCompleted(new ProcessImageCompletedEventArgs(imageResult.Image, imageResult.ISBN));
Thread.Sleep(SleepTime);
}
}
while (true);
}
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
Yep, that's exactly what the wait handle is for. Makes your app more efficient by not having the thread endlessly looping.
|
|
|
|
|
Cool cheers!
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
I agree with Ian's approach, which basically is tunneling all 3rd party accesses through a single thread.
However, it may not scale well, as in the end either the single thread tunnel or the web service itself will become a bottleneck. If the 3rd party package is slowing down under extra load, my first impression is it is running out of memory and starts to page to disk all the time.
Depending on what exactly causes the phenomenon, you could limit the number of outstanding requests to N (N to be determined and apparently less than 20). Either use a single thread and some logic to achieve this; or just launch N threads, each trying to find and launch one job at a time, all from a single queue (with appropriate lock while accessing the queue).
OTOH, if the web service itself is basically single-threaded (e.g. because a COM component is involved), then whatever multi-threaded stuff you add to feed it may not achieve anything.
|
|
|
|
|
Cheers for your reply Luc, informative as always
I am going to contact the 3rd party as well, as you say, i might be doing all this work for nothing if their end has limitations.
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
Remember that browsers to have their limitations - as in IE 8 (for e.g.) can open only 8 (or was it 6) asynchronous connections at a time. So even if your web services can handle tons of data (you are going to run into problems on the client side).
Firefox allows you to configure this limit.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
Visit the Hindi forum here.
|
|
|
|
|
The client is not a web browser, its a C# windows service. Sorry i did not make that clear.
Regards,
Gareth.
(FKA gareth111)
|
|
|
|
|
hi all.
i have a little Problem that need a help in my program.
I want to search for a field "Name" in the table "Person" of my SQLdatabase and save its ID in another table "Personel".
i do this through this code:
linqDataContext obj = new linqDataContext();<br />
var per = obj.persons.Where(item => item.Name == personCombo.Text).Select(item => item.Id);<br />
obj.PersonelSave(System.Convert.ToInt32(per.ToString()));<br />
I should say that Personel save is a procedure in my linq.dbml file
ALTER PROCEDURE dbo.PersonelSave @PersonId int<br />
AS<br />
insert into personel values (@PersonId)<br />
RETURN
and the error for my code is: "Input string was not in a correct format."
please help me to solve this problom.
|
|
|
|
|
Assuming you're getting the error on PersonelSave()... Set a breakpoint there, and see what the value of "per" is.
Also, what type is "per"? It's not a "Person", or whatever that class is called. If your Id field is numeric, then it's already a number, and you shouldn't be converting it to a string and parsing it back to an integer.
|
|
|
|