|
didnt help much 
|
|
|
|
|
I have a simple application that I am using to learn C#. The application contains two textbox fields and a button.
The program consist of a method that calculates the sqare root of a number (data type float)
How can I display the result in a textbox if the textbox only takes text
Example
result is res=1.5
textBox1.Text=res -- compiler error
thanx for the help
|
|
|
|
|
res.toString();
<italic>Work hard, Work effectively.
|
|
|
|
|
Some Samples:
<br />
decimal inputDecimal = Convert.ToDecimal(txtInputTextBox.Text);<br />
<br />
string myString1 = inputDecimal.ToString(); <br />
<br />
string myString2 = inputDecimal.ToString("0.00"); <br />
<br />
string myString3 = String.Format("{0:0.0000}", inputDecimal); <br />
<br />
string myString4 = String.Format("The Result is: {0:C}.", inputDecimal); <br />
|
|
|
|
|
hi
how i can make a stand alone c# windows application?
i want to use it somewhere without installing .NET frameworw.
thanks
|
|
|
|
|
ABBASI_RA wrote:
how i can make a stand alone c# windows application?
i want to use it somewhere without installing .NET frameworw.
Write it in C++. That's your only option. And don't use managed C++, or you'll need the .NET framework all over again
The reason everyone ships their .NET apps with a dependancy to the .NET framework is because that's the way it works. Your compiled C# program is not recognisable to any computer, the .NET framework is needed to compile it into a final executable.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
But, why can't Microsoft provide an option to prepare a stand-alone executable file in .NET for C# etc.?
Let there be an option for those who want managed code and dependency on .NET framework.
But let there also be an option for those developers who want their .NET application to be converted into stand-alone executable, may be at the cost of tying it with a particular operating system or processor-family. It is also possible for Microsoft to allow creation of stand-alone code for a particular OS (such as WIN XP) or a group of OS's. Later on the OS can have some mechanism to cater to different types of processor-family. In the olden days, in C compilers, there used to be an option at the time of compiling to "optimise" for a particular processor-family. Why can't Microsoft come up with some innovative idea?
At least, there could be something in the installation / setup program, which could convert the .NET executable to the stand-alone executable for that particular machine using utility such as ngen.exe . But, in such a case, the .NET IL (or MSIL) file containing all information about the coding should not be installed. Can there be a mechanism like this? Or, can Microsoft innovate such a mechanism which should not be difficult to imlement in .NET version 2.0?
If Microsoft wants a "transparent" code for other developers, why can't it make its own windows "core" code public?
|
|
|
|
|
Anonymous wrote:
But, why can't Microsoft provide an option to prepare a stand-alone executable file in .NET for C# etc.?
Because the whole POINT of .NET is the virtual machine, which can in theory be ported to other platforms. Even within Windows, this means that versions of the framework can be written to optimise code for specific processors.
Anonymous wrote:
Why can't Microsoft come up with some innovative idea?
They did. It's visual C++. What you're suggesting is a whole lot of work to give us what we already have. Being able to write to a common intermediate language so that we can mix and match languages is more of an evolution than a revolution, but it's still a decent idea IMO. If you don't like it, don't use managed languages.
Anonymous wrote:
Or, can Microsoft innovate such a mechanism which should not be difficult to imlement in .NET version 2.0?
Given that 2.0 is in final beta, even if this was an idea they were likely to take up, it would not be in 2.0.
The MSIL compiler does NOT create an executable in memory, it creates functions, one at a time. However, just like you need MFC as a DLL to run MFC apps ( unless you accept bloat in executable size ), even the compiled .NET executable is bound to call .NET libraries - why would they compile the code to manage regular expressions ( for example ) into every app instead of having them in a library ? So the size of the download might drop, but it would still exist.
Anonymous wrote:
If Microsoft wants a "transparent" code for other developers, why can't it make its own windows "core" code public?
What on earth do you mean ? Are you saying that your issue is that MSIL can be decompiled ? In fact, it can, and that applies to Microsoft's .NET code also. How does that mean they should give away all their code ? Should Coke be forced to give us their recipe ? What's the difference ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
They did. It's visual C++. What you're suggesting is a whole lot of work to give us what we already have. Being able to write to a common intermediate language so that we can mix and match languages is more of an evolution than a revolution, but it's still a decent idea IMO. If you don't like it, don't use managed languages.
In fact, what I was suggesting was that you have the best of both worlds as an option, i.e., the ease of C# and the advantage of stand-alone executable.
In any case, the main problem with managed code is that its MSIL code is so transparent that everything (including some portions of code such as licensing of trial version, encryption keys, etc.) can easily be seen by utilities like ILDASM and Lutz Roeder's Reflector. This problem is not so much with VC++, but then it is a difficult language comparatively. For a small developer for shareware etc., it matters a lot, though it may not matter for a big developer like you with Microsoft MVP status. So, it is a question of combining ease with features (i.e., some features at least as an option).
One should look at sharewares. How many sharewares are written in C# inspite of its ease? You will hardly find many. This is so inspite of the fact that C# is now existing for last 4 to 5 years. So, is it not that something is holding back C# from certain fields at least? I think C# is more useful for intra-company utilities and the like. If you want to launch a utility to the outside world, then you should be ready for an open-source treat for your C# application.
Christian Graus wrote:
What on earth do you mean ? Are you saying that your issue is that MSIL can be decompiled ? In fact, it can, and that applies to Microsoft's .NET code also. How does that mean they should give away all their code ? Should Coke be forced to give us their recipe ? What's the difference ?
I Don't believe in Microsoft bashing. Let them keep their code secret. But, don't you think that MSIL is slightly over-transparent, it does not permit you to conceal even a few secrets such as some important logic like licensing etc. The question is not whether MSIL can be decompiled, but whether it reveals all secrets. If it reveals all secrets, then sometimes decompiling may not even be necessary.
|
|
|
|
|
Anonymous wrote:
In fact, what I was suggesting was that you have the best of both worlds as an option, i.e., the ease of C# and the advantage of stand-alone executable.
Yeah, I get what you meant. However, as Nish said, you'd still need the framework, and you'd lose other advantages. Simply, it's not what .NET is for.
Anonymous wrote:
but then it is a difficult language comparatively.
Perhaps, but if this was easy, there'd be no money in it. That's MY problem with .NET 
Anonymous wrote:
a big developer like you with Microsoft MVP status.
LOL - being an MVP doesn't actually mean anything about the sort of development I do. As it happens, I work for a fair sized company, but I do a lot of work on my own as well. And I would agree with you that security of code is an issue, especially for trial versions, etc. However, if I wrote a trial version of anything, it would be missing major pieces of functionality, and I would not ship that code. Even C++ can be reverse engineered, and every protection will get cracked.
Anonymous wrote:
So, is it not that something is holding back C# from certain fields at least?
Perhaps. However, you're guessing what the reasons are, you could be wrong.
Anonymous wrote:
I think C# is more useful for intra-company utilities and the like. If you want to launch a utility to the outside world, then you should be ready for an open-source treat for your C# application.
Well, IMO, that's where most of the money is anyhow.
Anonymous wrote:
But, don't you think that MSIL is slightly over-transparent, it does not permit you to conceal even a few secrets such as some important logic like licensing etc.
Yes, I already agreed with you here. It's sadly a by product of how the framework works. I don't see any way around it for shareware type products, but I don't see that tiny market sector as a driving force for Microsoft to add something that is fundamentally useless to most people - the end exe will still need the .NET framework, and advantages of the framework are lost.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Even if there was a C# native code compiler, it'd be pretty useless since you wouldn't be able to use the .NET f/w classes, as that'd require the .NET f/w to be on the target machine.
|
|
|
|
|
Yeah, that was my point also....
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hello,
What I am trying to do is to add some radio buttons to a GroupBox dynamically. The number of radio buttons to add is differnet from time to time so I used a foreach loop to add the buttons to the GroupBox. But unfortunately, the GroupBox displays nothing apart from its border. Here is the unworking code:
GroupBox choiceGroupBox = new GroupBox();<br />
int buttonY = 0;<br />
choiceGroupBox.SuspendLayout();<br />
<br />
foreach(Object choice in choices)
{<br />
RadioButton button = new RadioButton(); <br />
button.Text = (string)choice;<br />
button.Location = new Point(16,buttonY);<br />
choiceGroupBox.Controls.Add(button);<br />
buttonY += 5;<br />
} <br />
choiceGroupBox.ResumeLayout();
I don't see anything wrong with this code but the GroupBox simply displays nothing......
This problem seems only happens when the radio buttons are created on the fly since I've tried to add a single radio button to the GroupBox and GroupBox works perfectly.
Could any one point me to something working? I am really getting mad with this "small" problem .......
Thanks in advance!
|
|
|
|
|
Maybe Choices is null ?
Be sure that those conreols are visible, Try first to put them on any panel .
|
|
|
|
|
really thanks for your reply LongHC. choices was null.
|
|
|
|
|
|
Really ? I thought that maybe Visible needs to be explicity set, but I thought 'surely not' ? Enough so that I didn't even bother testing to see.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
Really ? I thought that maybe Visible needs to be explicity set, but I thought 'surely not' ? Enough so that I didn't even bother testing to see.
I recently had a similar problem. The problem is that the controls are being added after the Form's Show() method is called.
Though, I'll go back and check just to make sure this is the problem.
Marc
My website
Latest Articles:
Undo/Redo Buffer
Memento Design Pattern
|
|
|
|
|
I'm not doubting you, just doubting the sanity of the behaviour.
I guess it allows you to add controls for showing later, without them ever flashing onto the screen, although setting visible to false before adding them to the controls collection would achieve that also.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hey!
I am using System.IO.SerialPort in framework 2.0(Beta2) to listening on the port. I am also using DataReceived event on the serialPort object.
I have set the threshold to 1, this means that the event(DataReceived) will fired as soon as 1 byte is written to the serialport.
When this event is triggerd, I am using a ThreadPool to queue work to my OnRecivedData() method.
In OnRecivedData() I first reads existing on the serialport, but I also writes this icoming data to file.
To see if this realy got what it takes I have made som test. I am sending data as fast as posible over the nullmodem cable with the follwing port settings:
Baud: 11 5200
Data: 8
Parity: None
Stop; 1
Problem:
I have compared the file that I send, and the file I recived(creates) and this works fine in low speeds, but whenI am pushing the system to 100% load my program by moving around a window or something, It loses data?
I realy have to get a stable connection even during stress.
I first thought that I could set the ThreadPool to a higher priority, but I havent found any way to do this? It could also be the evnet(DataReceived) that is never fired, can I set higher priority on this event?
Best Regards
SnowJim
|
|
|
|
|
Your code for recieving data should itself be in a worker thread, so that it continues to function even when the UI thread is maxed out by you moving a window.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Yes, as I said, I use ThreadPool as soon as the event is triggerd.
Or do you mean that i need a separate thread for the event? I thought that when an event accure, then a new thread is automatly created to handle this event? or is it the main(GUI) thread that will be used to the event? And if so, is there any way to get an own thread to this?
BestRegards
SnowJim
|
|
|
|
|
It really shouldn't be losing data, under any circumstances. Did you view the file after closing the application? Maybe it was just getting buffered in memory?
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
Yes i know that there may be a buffert. But this buffert is flushed and writen to the file.
If i dont move the Window around so i get 100% CPU usage, the transfere works fine.
It is not losing data in the end, its on diffrent places al the time, and its often some lines of data(maby 5-6 that disipares?
But the Thread that runns the event? is this Thread, the same as the main thread(the thread that draws the GUI)?
Best Regards
SnowJim
|
|
|
|
|
Hmm. How are you running OnReceived? Are you using ThreadPool.QueueWorkItem or the BeginInvoke method on a delegate object? If so, your function is running on a separate thread, not the UI thread. However, if you are calling BeginInvoke on an object derived from Control (like Form, TreeView etc..) then the function will run on the main thread (UI thread).
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
