|
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.
|
|
|
|
|
I'm doing a C#/.NET home project, and need - from within C# code - to access some sort of dictionary database. The ONLY requirement is to test if arbitrary strings match to real words or not - I do NOT need any of the other dictionary or spell checker stuff, such as alternative-word-suggestions, nor word meanings ... just is the string in the dictionary or not. Not sure about plurals though?!
This is an educational exercise, so I'm definitely hoping for some kind of freebie.
If anyone's got any got ideas I'd be very grateful ... thanks.
|
|
|
|
|
If the idea is not in database usage, you could look at DataTable and DataSet and it's serializing capabilities (along with other features).
|
|
|
|
|
Many thanks. What I'm really trying to fathom is:-
1) Where do I get the dictionary info from in the first place. I need something someone else has already created - I don't have the knowledge to try creating dictionaries from scratch.
2) I need it in a form such that I can interrogate it programmatically. I want to present an arbitary string to it (from within C# code) and get it to return a value indicating if the string matches a known word or not - nothing more.
3) I would need the dictionary to recognise both singular and plural forms.
Best regards,
|
|
|
|
|
|
Excellent - your Google search was much better than mine! And yes, the storage format will have a big impact on the search time - some sort of successive approximation approach seems likely.
Thanks
|
|
|
|
|
|
This sort of thing has come up before and I don't remember what site the asker was directed to.
I wrote my own such thing a few years ago as a Scrabble aid. I got an enormous list of words* from a Scrabble website and imported them to an Access database.
* Actually two lists; one is 2.3MB, the other is 1.6MB and seems to be missing the non-kid-sister-friendly words.
Where shall I send them?
|
|
|
|
|
Here's[^] a link to the message I remember.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
