|
RezaAsAdi wrote: can i use any library or object model to send a SOAP message over HTTP inside a Windows application?if I'm inside a WEB application I can use "Post" method to send a message,but what about a Visual C# Windows application,there is no any object which has "Post" method there.
Yes, in all forms of modern Windows development ( this includes .NET therefore C# ) you will find libraries available from Microsoft that simplify working with SOAP and making HTTP requests as a client. However, as with all standards, there is a possibility of two different library implementations producing an incompatibility. With SOAP being so pervasive the chance is small, but it could happen. The simpler your use of SOAP is, the less likely you will encounter any.
|
|
|
|
|
Thank you very much led for your immediate and clear answer 
|
|
|
|
|
Hi Buddies...
I use clickOnce for publishig my application ...
But when It publish
Ex. I am publishing Version 1.0.0.2
then after publish it ask for "Whether To Install new version or not ?"
If user click on skip button It wont get the latest version and it still
uses older version,untillI dont publish next version ...
Is there any facility in VS that each time it ask for latest version
When user runs that application and if he is using older version.
|
|
|
|
|
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
when i try to read large amount of data from online and add it to my combo box this error occurs what can i do...
send me suggesstions...
|
|
|
|
|
Hi,
Is this exception raised when you tried to fetch data from database server,then
set the Connection Time out property to 0 (infinite).
Tarun Singh
|
|
|
|
|
public SqlConnection objCon = new SqlConnection("Data Source=VEESERV2;Initial Catalog=Inventory_VS;User ID=sa;Password=sa;Connect Timeout = 60");
is it right?
|
|
|
|
|
kulandaivel_mca2007 wrote: User ID=sa
Seriously - Never connect to your database as "sa" you've just punched a very large security hole in your application.
kulandaivel_mca2007 wrote: Connect Timeout = 60
This is the amount of time you are willing to wait for the connection to be established. It defaults to 15 seconds.
Your error message suggests that you have already made the connection, you are just waiting for the results. You therefore need to set the CommandTimeout on the command object. It defaults to 30 seconds.
I do not advise setting to 0 (infinite) as your program will hang until it has the result.
If your query is taking so long, you should also look optimising it. It may be that your query or database are set up very inefficiently.
|
|
|
|
|
That means that you wait for the connection for 60 seconds max. As Colin pointed out there are several issues in your connection string.
However, if you're executing a query, is it really a problem in geting the connection or is the problem occuring when executing the query (after a connection is made). If it's in the query, the connection timeout has nothing to do with the problem. In that case you should try to optimize the query itself.
|
|
|
|
|
Is there any place I can download Microsoft WinFS Beta 1 to have a look at ? Anybody have a copy in their archives or cds they can upload and share...
thanks in advance
abm_v@hotmail.com
|
|
|
|
|
About the only place you can get a copy of it is MSDN SUbscriber Downloads.
WinFS was cancelled in 2006. It was mentioned by Steve Ballmer that work on the project did not stop and the technology does still exist in various forms, but not as a complete file system. The various pieces of technology are being integrated into future versions of ADO.NET and SQL Server.
Is it completely dead?? Maybe, maybe not. The WinFS team blog stopped being updated back in June 2006. Draw your own conclusions...
|
|
|
|
|
please give the answer
sibasish
|
|
|
|
|
Please use a search engine, such as Google or Yahoo, to get this answer. It'll take you all of 5 seconds to find the answer.
All you have to type in is "What is a WebService", or "What is a Windows Service".
|
|
|
|
|
|
1)Webservice is a Platform Independent,where as windows service is a platform dependent.
2)Webservice should be called inorder to invoke.Windows service gets invoked automatically based on schedule.
Sivaramakrishna popuri
www.sivatechspot.blogspot.com
|
|
|
|
|
What is the best way to handle a task which must be performed on the UI thread, but which may take awhile to complete (e.g. a slow control update or redraw)? One approach would be to do part of the task and then BeginInvoke a routine which will do the rest (possibly by itself doing part and using BeginInvoke again). That approach, however, could end up wasting a lot of CPU time handling the BeginInvoke operations in cases where there isn't anything else for the UI thread to be doing and the tasks could have been run to completion.
Is there any good way to say "Run this code if there isn't anything better for the UI thread to do", and then (within that code) ask "Has anything else come up the UI thread should be doing"?
Alternatively, are there any tricks that would allow a control to be drawn within its own thread? I would expect interaction between the control and the rest of the form would have to be handled on the form's UI thread, and the control would have to have a means of queueing things like resize events from the UI thread and dealing with them sensibly, but if a control would otherwise take a little time to render being able to handle the rendering on its own thread would be helpful.
|
|
|
|
|
Could you explain why this has to be run in the UI thread? The purpose of the UI thread is very specific...to manage the UI. Most of the time application logic can be run synchronously in the UI thread because it only takes moments to complete. However, any long-running processes should be separated into application logic and UI logic, and the application logic should be run in a background thread.
You have many options for keeping a UI in sync with work that is being done in the background. You can use Control.Invoke to invoke operations in the UI thread from your background thread. You can use a BackgroundWorker with progress reporting on to periodically report progress from your background thread with user data for each event. You can execute methods asynchronously with delegates or use the ThreadPool and worker items to manage background tasks. The .NET framework also offers a lot of thread synchronization features, rooted in the WaitHandle class. You can use WaitHandles to create signaling between threads, without having to constantly start and stop each worker with explicit calls to BeginInvoke or the like.
|
|
|
|
|
Sometimes updating or redrawing a control can take a non-trivial amount of time. Not necessarily a huge amount of time, but non-trivial (say, 100ms). Control redrawing has to be done on the UI thread, but blocking the UI thread for 100ms at a time can make the application feel "chunky". It would seem better to allow other things to take priority over the control redrawing when there are other things to be done.
In some cases the right approach would be to have a different thread draw the control contents in an off-screen bitmap, and then make that bitmap available to the UI thread. Such an approach would not be without its own drawbacks, however. Having each control create a separate thread for processing would be wasteful. Having all the controls of a class share a thread might be better, but unless the controls contain logic to subdivide their work a slow control could delay action on the rest. Even in the absence threading issues, processing off-screen bitmaps and copying them is generally slower than drawing directly to the screen.
Incidentally, what should be the normal pattern for controls which allow actions that may take awhile to complete (e.g. setting the RichTextBox's .rtf property)? Microsoft's controls require that most actions be performed on the UI thread, and they'll block the UI thread for as long as the actions take, but that seems rather icky. I'd like to design any of my own controls to avoid such blocking behavior in the UI thread.
|
|
|
|
|
Given the nature of how UI works in a classic Forms app, I am not sure that drawing on an alternate thread is really feasible. I'm not even sure its desirable, either. There is a difference between a responsive UI, and a UI that is usable but not completely drawn. As a user, I would expect that when my UI is redrawing (if that redrawing takes a while) that it fully completes that drawing before it returns to me and allows me to edit content. If I am allowed to edit content in an incomplete UI...I would feel that the program is just asking, if not begging, me to make an edit on stale or incomplete content.
If you need a highly responsive UI, you might want to look to WPF. Windows Forms is bound by the classic and somewhat legacy way that UI works in Windows...based on a message loop and blocking redraw actions. WPF, on the other hand, is a very modern system that allows drawing activities to be fully hardware accelerated. You are even free to write custom shaders to render your controls, or render effects on your controls. Given that its hardware accelerated, lag time should be well below that 100ms mark unless your processing significantly more data than is actually visible in the UI (i.e. the RichTextBox control, which processes the whole .rtf before rendering the viewport....it should just process the part of the RTF that is visible in the viewport).
|
|
|
|
|
As a user, I would expect that when my UI is redrawing (if that redrawing takes a while) that it fully completes that drawing before it returns to me and allows me to edit content.
If one is using an MDI application, all child windows of a form must be drawn by the same thread. While the system should ensure that anything the user thinks he's editing is actually there, that doesn't imply that a user should be forbidden from editing anything (even in other windows!) unless everything is current.
There are many applications that operate on the general principle I describe. Google Maps, for example, allows the user to pan around a map without having to wait for everything to be updated. I hardly think that service would be improved by requiring that the user wait for each screen update to complete before being allowed to pan or zoom, or even close the application for that matter.
Of course, Google Maps happens to do updates in nice big chunks because that's how its data-transfer facilities are set up, but that doesn't mean that's the best approach for applications where data is locally available but may take a little time to render.
|
|
|
|
|
The fundamental nature of Google maps is a bit different...your only viewing, not editing. In that case, sure, delayed updates work fine, as there is no chance the user will modify incomplete information.
|
|
|
|
|
Many of the controls I design are essentially view-only, and I expect that's not particularly unusual. Even edit controls, however, shouldn't IMHO ever block the UI thread for more than a small fraction of a second. If the control needs to do something that may take awhile, it should allow the UI thread to run in the mean time even if the control itself shows a "busy" indicator and is not functional. A recent article seems to deal with this subject, so I'll have to see what I can make of that.
|
|
|
|
|
What type of control are you talking about? Some controls provide methods like BeginUpdate which can be used to prevent control from drawing until you call EndUpdate.
supercat9 wrote: Incidentally, what should be the normal pattern for controls which allow actions that may take awhile to complete (e.g. setting the RichTextBox's .rtf property)?
You can use a worker thread to load the data into memory and let UI thread read from the memory to fill the control. But still you will see some delay if the data is too heavy and I don't think that there is a method to avoid this.
|
|
|
|
|
In the particular immediate case, I'm thinking about a control that's somewhat like an enhanced ListBox which allows for the possibility of a list item changing height. When the width of the control is changed, its items get a chance to redetermine their height. My plan is to do this first for the items on the screen, and then for everything else; all items would have to be measured to set the scroll bar accurately, but I wouldn't want to hold up the entire UI thread for that.
If the control were an opaque class, it might make sense for the measurement to be done in a background thread. Since it is not, however, it would seem like very poor style to have a background thread call the list contents' measure-item methods which may not be expecting invocation outside the UI thread.
|
|
|
|
|
At worst, you could call Application.DoEvents to run any pending UI operations. Beware of issues like reentrancy though.
|
|
|
|
|
I suppose Application.DoEvents might not be totally evil in that circumstance; maintain a flag to ignore recursive calls and the rest of the UI should be able to function while the updates are completed. It would be nicer if there were a version of Application.DoEvents that would only handle certain events while ignoring others, but I don't know of any such beast.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
