|
Hi!
I'm curious about if anybody is using .NET in desktop application development. I've just finished a live chat front-end using Windows Forms in C#, similar to Humanclick. Did not used any code obfuscator, mainly because the front-end itself don't have utility without the server's components (the windows service it uses and the aspx pages used in administration), so having people disassembling it is not a big issue.
I'll distribute the front-end to my customers along with .NET framework runtime and other stuff on CD-ROM, but will let customers to download it from web too. Now comes the big question: The .NET framework runtime is about 20Mb. Does somebody developed an application which requires the user to download the runtime? Will them install it? Or .NET is being used only for server side application development?
Thanks,
John
|
|
|
|
|
Microsoft answer are :
- the .NET run-time is soon part of the operating system, so it's not a problem anymore. Besides that, beginning with XP SP1, the .NET run-time is part of the service pack (XP SP1 CD).
- .NET run-times can run side-by-side, hence users will be able to have both the (current) 1.0 release and soon coming 1.1, and actually have applications to work with the appropriate run-time.
Of course, that's a lot of marketing. First, I can't see shareware authors distributing software that require 20MB++ (and ++ is up to 180MB) of binaries before they can start your app.
In addition, the application author must have anticipated a built-in .config file to manage seamlessly the case of multiple .NET run-times installed on the same machine. Otherwise, it fails miserably with a stupid MS error box.
I can see in-house desktop app development using .NET, that is in environments where deployment is not an issue. I don't see for the foreseeable future high end customer .NET desktop apps. But may be that's only me. 
(That's a totally different story when we are dealing with server-side : ASP.NET, web services, ...).
|
|
|
|
|
.S.Rod. wrote:
I don't see for the foreseeable future high end customer .NET desktop apps. But may be that's only me.
I agree, however, I am always reading that .NET is replacing WinAPI,MFC,etc., but I really don't see that happening for pure desktop application development.
Sometimes I wonder if when I work with MFC/ATL, am I just wasting my time with a technology that will soon become extinct?
R.Bischoff | C++
.NET, Kommst du mit?
|
|
|
|
|
Soliant wrote:
I agree, however, I am always reading that .NET is replacing WinAPI,MFC,etc., but I really don't see that happening for pure desktop application development.
Custom Windows form controls require WIN32, so I don't think that, with GUIs getting more professional every day, we are seeing WIN32 going offphase anytime soon.
Without WIN32, the CLR does nothing. So, if you have capitalized on WIN32 libraries, you are not wasting your time.
Soliant wrote:
Sometimes I wonder if when I work with MFC/ATL, am I just wasting my time with a technology that will soon become extinct?
How could MFC/ATL become extinct ? You have the source code for both libraries (you can even recompile them), so it won't become obsolete as long as you don't deltree them!
That said, yes, MS is trying to make us switch to .NET. The fact that all content in MSDN mag and MSDN library is now related to .NET does not have to make you and your company feel like MFC/ATL is over. MS is not investing anymore in those, but who cares?
|
|
|
|
|
I am developing a desktop app using .NET, and it is wonderful. Yes, you need the .NET runtime, but you can include it on your installation CD if you have one.
The great thing about .NET is how easy and seamless it has made developing components and user controls. It's now a true peice of cake, basically it is COM the way it was always meant to be (even Don Box thinks so according to an associate of mine who knows him).
Here where I work, the goal is all new development in .NET. And we don't take those decisions lightly.
|
|
|
|
|
jpwkeeper wrote:
I am developing a desktop app using .NET, and it is wonderful. Yes, you need the .NET runtime, but you can include it on your installation CD if you have one.
Indeed. .NET is wonderful.
jpwkeeper wrote:
The great thing about .NET is how easy and seamless it has made developing components and user controls. It's now a true peice of cake, basically it is COM the way it was always meant to be (even Don Box thinks so according to an associate of mine who knows him).
Here where I work, the goal is all new development in .NET. And we don't take those decisions lightly.
I have used .NET for building my last 2 projects, an accounting system with lots of XML handling, and the live chat system, with sockets handling, XML, multi-threading, and other stuff that can be a bit harder to develop/debug when using C++/MFC and those crypt COM interfaces... I think .NET is a great framework for building any kind of application. We can still use C++ for some work that needs very high performance. Sadly, I have heard about people and some companies that don't want .NET installed on their computers... I just don't know why...
Cheers,
John
|
|
|
|
|
John Mautari wrote:
Sadly, I have heard about people and some companies that don't want .NET installed on their computers... I just don't know why...
I have heard about people and companies that use macs... I don't know why either...
|
|
|
|
|
I'm having a problem where I run out of window handles, even though the number seems to be within the realm of the sane.
What I'm doing is creating a scrollable list of bar charts. The bar charts are interactive, so what I did was make each bar a separate control. This made selecting, floating tooltips, and many other things very easy. They're built dynamically. I was very proud of this idea.
Now, I have 100 bar charts, with 108 bars (in this case) each and say 12 other controls per chart (may be slightly less than that). That only amounts to 12,000 window handles, which even on 95/98 should be OK and I'm running XP Pro. I can't imagine that my main app window is using over 4,384 window handles.
When I hit my AddRange, I run out of window handles and get "Error Creating Window Handle".
I can't even do this with 50 charts. Any ideas on how to work around this without having to re-write my bar graph displays? Also, any idea on how spy on my application's window handle usage so I can determine exactly what I'm up against?
John Woodard
|
|
|
|
|
Can you provide some sample code and tell us what you're using to write this? I've built something very similar to what you describe but using GDI with C++. I had a resource leak problem once where I wasn't freeing my resources soon enough. After a while, the app just crapped out because it had maxed out the GDI object limit. The only way I knew to debug that was to add a column to the process tab in the Task Manager and watch to see when the GDI object count started getting out of control while stepping through the debugger. Not sure it's the same issue here, but it would help if you gave a little more detail.
Thanks.
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
|
perlmunger wrote:
I had a resource leak problem once where I wasn't freeing my resources soon enough.
That sounds about right.  ALLWAYS kleen up your mess
MyDUMeter: a .NET DUMeter clone
|
|
|
|
|
Being a C++ programmer I understand where you're coming from. I'm a C++ programmer as well. However, this is not C++, and it's not a leak. I can't easily post the code.
First of all, this is managed code. This is further proven by the fact that if I switch to a smaller list after the problem has happened, I can continue to run.
Second, it's not like it's happening due to repeated operations. I can run all day, so long as I don't have too many controls up at one time. The first time I graph 100 at a time I fail, but I can choose 20 different lists of 10 in sequence and I still work fine so long as I don't do it too fast (so the GC has time to catch up).
What it appears to be is that I'm limited to 16384 window handles. if each control has a window handle, that means 2 per bar (one for the bar, which is a UserControl, and one for the ToolTip window I assume), 108 bars per graph, Around 12 extra for scales and such on the graph, that's 24,000 window handles. This is almost certainly the problem. I changed it so that instead of a full-out control, each bar is defined by a helper class that renders it and the problem went away (obviously the helper class doesn't use a window handle, it just has the paint code). My question is, can I get around the 16K limitation (if that is indeed the limit)?
|
|
|
|
|
jpwkeeper wrote:
that means 2 per bar (one for the bar, which is a UserControl, and one for the ToolTip window I assume), 108 bars per graph, Around 12 extra for scales and such on the graph, that's 24,000 window handles.
You mean all the "bars" are seperate controls?  GDI is a must! I dont even wanna know how much memory this thing eats!
MyDUMeter: a .NET DUMeter clone
|
|
|
|
|
O yes, have a look at my MyDUMeter article. I do some "graphing" in there. Have a look at the ReportForm. Might be of some help.
MyDUMeter: a .NET DUMeter clone
|
|
|
|
|
Anyone looked at accessing a CORBA Orb from C# or from another .NET language.
Thanks,
Giles
|
|
|
|
|
hi!
how can i do that near of my TreeNode in TreeView to be a '+' if in subdodes of these nodes was nothing until exand it.
i want to fill node when expanding..
thx
|
|
|
|
|
subscribe for the OnBeforeExpand event.
|
|
|
|
|
I use a process in which I first only load the first three "generations" of the treeview. Then in the BeforeExpand event, I populate that node's grandchildren. Therefore, any time the user sees a node, it always shows its expand icon (the [+]) if it has children.
Jim Stewart
|
|
|
|
|
I am about to start writing some components in .net that will need to interact with an LDAP directory (Not MS Active Directory!)
Can any one send me any pointers?
Thanks
|
|
|
|
|
System.DirectoryServices should work with any LDAP server.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
|
|
|
|
|
The following code loads the contents of a web page (Page) into string PageText:
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(new Uri(Page, true));<br />
request.Method = "GET";<br />
<br />
HttpWebResponse response = (HttpWebResponse) request.GetResponse();<br />
Stream responseStream = response.GetResponseStream();<br />
StreamReader reader = new StreamReader(responseStream);<br />
string PageText = reader.ReadToEnd();
The problem I have is that the page I receive comes back with encoding that doesn't show up correctly in a text box. For example a single quote ’ comes back as & # 8 2 1 7 ; (without the spaces). I think that this would be correctly displayed in a HTML viewer, but how do I get it to display correctly in a text box?
Putting an encoding in the constructor for the StreamReader seems to make no difference.
Thanks in advance,
Keith
|
|
|
|
|
Would the System.Web.HttpUtility.HtmlDecode() method work?
|
|
|
|
|
This is a C# application and not ASP.NET code or a WebService. Therefore I don't have access to the System.Web namespace. Sorry, I should have mentioned this first time.
Thanks for the response.
Keith
|
|
|
|
|
Did you tried System.Net.WebClient?
<br />
using System.Text;<br />
using System.Net;<br />
<br />
...<br />
<br />
WebClient request = new WebClient();<br />
string PageText = Encoding.Default.GetString(request.DownloadData(Page));<br />
Cheers,
John
|
|
|
|
|
I've tried this but the result is exactly the same regardless of the encoding.
|
|
|
|
|
What happens if you use:
<br />
...<br />
string pagetext = Encoding.ASCII.GetString(request.DownloadData(Page));<br />
...<br />
Sorry if you already have tried it... 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
