The .NET world is a totally different beast. C# or any of the other langauges are only the least of things. The framework is what has moved me to .NET as much as anything else. I do not remember for sure but it is something like 8,000 class and it is a fully class based framework, no more SDK.
If you are not developing something machine dependant (this includes heavy graphics), I doubt you will find much missing. I have worked with it now for two years and have not had any stoppers.
The C# language is of course my favorite but that comes from a background of twenty years of C/C++, so it is the closest.
There are a few quirks in the langauge, but overall it is okay. Being able to use other modules from VB.NET or others is really nice.
I will warn you though, be prepared to rethink software design in general. There are so many ways of doing things in .NET that it can be time consuming figuring out the best way to go. Now that we can so easily combine networking and software, the scope of our programs are increasing.
Why settle for some silly import of data when you can use a web service and streamline it. Maybe you application is a resource hog, now you can easily spread its tasks over multiple computers with .NET remoting (that actual works ). Now that we can use a lot of the backend of applications for both web and windows application, we have to start thinking even more of reuse of code.
Now, for time savings!! Yep, it has drastically cut down my development time. I do not know about you, but for me I usually run at 25%-40% of the time of application development debugging. This can range from simply null pointers or dll mistmatches up to several days tracking down bugs.
Not with .NET. My debug time has dropped to almost nothing. Maybe 1%-2% of the time I will be debugging. Very trival now compared to the old C++ days. The code is so simple that errors jump in your face quick quickly. Also a huge reduction in coding since I get more done with less, so it is less to debug.
And remember, this is only the first version, 2.0 is supposed to be a lot better
Of course all this will help when Longhorn comes to market
I consider the views of other devleopers to be far more reliable than the advertising from Micrsoft. However on this occasion you appear to have very little bad to say about C#. I think I shall give it a go.
How can we get the 'Folder Browser Dialog' like ,we have have standard 'file open dialog'. Is there any component in .net providing this capability? or is there some APi, we have to use in order to open a folder browser dialog.?
There is System.Windows.Forms.FolderBrowserDialog in .NET 1.1 and up. For applications targeting .NET 1.0, you'll have to create a look-alike or encapsulate the SHBrowserForFolder API. There are several articles here on the CodeProejct site that discuss the latter option. The component I mentioned first is very easy to use, just like the OpenFileDialog and SaveFileDialog components.
I have questions about paging
Because paging may play important role in distributed application
And according to ".NET Data Access Architecture Guide" at MSDN there are three options to
1-Use the Fill method of the SqlDataAdapter to fill a DataSet with a range of results from a query.
2-Use ADO through COM interoperability and use a server-side cursor.
3-Implement data paging manually by using stored procedures
the article discuss this options
Each method have its advantage and disadvantage in performance and scalability and other things
the question is
What option you use in your Distributed Application and Why ?
If you have another method what is this method at what is it's advantage over those methods
thanks in advance
It greatly depends. Over what medium is it distributed? Does each client share in the processing of specific chunks of data?
If this application is deployed over the Internet using a DataSet is good because it is both serializable (which is good for both XML Web Services and .NET Remoting) and disconnected (better throughput). If each client processes parts of this data, you'll need something to delegate to the clients which rows they should be working on, or fill a DataSet with only the data they should process.
If your clients are on a LAN with the server as opposed to a WAN, the second method might be good because the server cursor will make sure that each client is accessing sequential data in a distributed manner. For an Internet application - as I mentioned above - the rate of data exchange will potentially be high which will result in congestion. You'll also have to take lengths to ensure that any data you in any object you send is serializable to transport via XML Web Services or .NET Remoting. If you use raw sockets, serialization isn't a problem but you might have problems using sockets (for instance, securing them if they need to be secured and bi-di communications can be combersome.
As far as stored procedures go, you'll still need something to track which block of records to delegate to the next client. A Singleton object exposed through .NET Remoting could help and it won't even have to worry about serializing data if you just pull it using a SqlDataReader or something. If this is a WAN- or Internet-deployed application, a SqlDataReader won't work, and even if it did it would create a high rate or smaller chunks of data which could lead to congestion and timing issues.
Depending on your answers to the first two questions, I hope the following paragraphs are of some help to you.
Thanks Heath , Guillermo
i agree with you but i have a comment about using Ado server side cursor
as heath mentioned some of its advantage i see that keeping long time open connection
with the database server and the number of the round trips between the client and server
may be unaccepted and may be this solution violate the philosophy of ado.net
what i want to say make this last solution.
what is your opinions ?
TO Heath :
i posted another quetsion about paging decision at sql,ado.net forum may you take a look?
I completely agree with Heath. All depends on how you are planning to deploy your application.
I'm just finishing a distributed application, and the enviroment I'm using is a LAN, so the customer wanted online notifications of data update.
What I did was build a service that listen to all modifications done by the clients, and fire events when the update is complete, so all the clients listen to those events and react depending on the data they are showing at the moment.
I used disconected data (DataSet and DataTable).
A simple Client / Server architecture, but it works perfect and fast in a LAN enviroment.
I have constructed a COM object in VB6 that exposes various methods to handle custom files. This object works very well when I use it from a normal VB6 project, but when I use it through COM Interop in a C# application a strange error appear:
Inside one of the functions in the COM dll I use the FileExists method on a FileSystemObject. When this method is called from the C# code FileExists returns false, even though the file exists. When the same method is called with the same filename as parameter in VB everything works.
Anyone who have any idea of what I am doing wrong?
You should debug both projects (start debugging the C#/.NET client in VS.NET and then start your VS6 and attach to the process) and see what string is getting passed to the COM object. The behavior shouldn't really change from caller to caller except when parameters differ. A different value might be getting marshaled to your COM object than what you're passing from your C# code.
My initial thought is that there is a Unicode vs. ASCII problem with string encodings. .NET stores Unicode strings internally and your VB6 control might not be expecting that. See the VB6 StrConv function for information pertaining to converting from/to Unicode strings.
No, it would be an access problem if one client could access it via your COM component but another client couldn't, unless they were running with different credentials (something you have to manually do through several steps). This sounds more like a marshaling problem as I mentioned before.
Your COM component can only run as an out-of-process server if it is a stand-alone executable (.exe), so that's not even a valid case.
Since it worked before, you're obviously doing something right. Since it changed, you should figure out what changed. Two compiled applications don't magically change. If this is a marshaling problem, make sure you understand that Windows 9X/ME (Windows) use ASCII while Windows NT/2000/XP(/future versions of Windows) (Windows NT) use Unicode. I can't remember exactly how VB handles strings, but you can code your .NET applications to P/Invoke methods using either ASCII or Unicode depending on the OS type, which it will automatically do for you (see CharSet.Auto). I don't remember exactly how VB deals with the different OSes. Find out how that works and make sure your .NET application marshals the string accordingly appropriately on either of the Windows OS system type.
I have created my own Rebar Control and I am having issues on Windows 2000 machines.
When creating the handle it throws an Win32Exception with the error "Invalid window class name". It works fine on Windows XP machines.
The following is my CreateHandle method and CreateParams property. Any ideas?
protected override void CreateHandle()
// Initialize Cool Bar Common Control
INITCOMMONCONTROLSEX initCommonControls = new INITCOMMONCONTROLSEX(); // I set Size field in constructor
initCommonControls.Flags = InitCommonClasses.COOL_CLASSES | InitCommonClasses.BAR_CLASSES;
base.CreateHandle(); // <-- Exception thrown here
You must make sure that your window class is registered using RegisterClass(Ex) API. InitCommonControls does this for classes defined in the common controls library, but any custom classes must be registered by you.
I found out what is was. The INITCOMMONCONTROLSEX structure had the size and flags fields the wrong way, so the call to InitCommonControlsEx was failing. It's just weird that it worked fine Windows XP, sometimes is really bad for developing on, because it hides errors.
Here's an idea: How about in the OnMouseDown set a flag to say the mouse is pressed, in the OnMouseUp reset the flag back to its initial state. Then in the OnMouseMove event you can check the status of the flag to determine if the button is pressed or not.