|
Uh, why would you do that? You can't compile C# to a form that doesn't require the .Net Framework (as far as I know), as that's what the language is built for (and it implicitly relies on framework things like the CLR type system, the garbage collector etc).
If you want to write a native DLL, do it in a language that compiles to native code (e.g. C/C++, Delphi/Pascal, etc). If you want to write in C#, make a .Net component (with an exported type library if you need it from native code) and use the managed API to the serial port.
|
|
|
|
|
Hello Everybody,
I have a Blank WPF Window. In which i want to add button at the time of Window load.
How can i add Button in WPF form by using C# Code.
Thanks
If you can think then I Can.
|
|
|
|
|
This would be better asked in the WPF/Silverlight forum.
|
|
|
|
|
Maybe it is an option to add the control in design time and set visibility to false. In the onload event of your window you set thatproperty to visible.
V.
|
|
|
|
|
Hello Everybody,
How can i know that size of Object at the time of declaration of object.
If you can think then I Can.
|
|
|
|
|
That's what sizeof()[^] is for.
Use it with the type of your object and it will tell you, how much memory will be used to create an instance.
Ciao,
luker
|
|
|
|
|
sizeof() is only good for value types. What happens if the OP wants to measure a reference type, such as a custom class or List etc?
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
Wayne Gaylard wrote: What happens if the OP wants to measure a reference type, such as a custom class or List etc?
Marshal.SizeOf[^] 
Bastard Programmer from Hell 
|
|
|
|
|
In .net you can never know how much memory an instance of a random class will require. In fact the memory required by different instances of the same class can vary and the memory required by one instance can vary during its lifetime.
|
|
|
|
|
How large can bitmaps be in C# VS2010 W7 64 bit?
Thanks to all for the replies.
modified on Thursday, September 15, 2011 7:36 PM
|
|
|
|
|
Depends on the memory (capacity) of your system.
Too much of heaven can bring you underground
Heaven can always turn around
Too much of heaven, our life is all hell bound
Heaven, the kill that makes no sound
|
|
|
|
|
Depends on several factors, but in general, no single object (Bitmap or no) can be larger than 2GB.
|
|
|
|
|
Can you define single object in this context?
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Any single instance of anything in .NET is restricted to 2GB.
No class instance can exceed this, but an array is a separate object, so you could have an array of 2GB bitmaps without problems (as the array is just a list of references - you know this but I thought I'd spell it out for the Q&A crowd who might have got lost).
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
Yah missed the restriction of c#, I was thinking I have images, files, MDFs all somewhat larger than 2gb
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Really? My vhd is 16GB in one file... 
V.
|
|
|
|
|
Files are fine - but you can't load the whole thing into any single object as that would exceed the .NET 2GB limit.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
|
|
In addition to the answers about single object, there is also a difference between 32 and 64 bit applications in how much memory they can address. I am not sure how this works out for .NET, but for a general Windows application a 32 bit program will have, at best, around 3 GB's of memory in its address space. This is then filled up even more with loaded DLL's, file handled, objects, etc, so it could be considerable less than that.
For 64 bit, you have relatively unlimited addressable memory available. However, the actual amount you can use is still limited by physical memory, page file and other factors. Also, the 2 GB per-object limit probably still applies. Furthermore, it is always easier to allocate a lot of small chunks than to allocate one big chunk, so creating 4 512 MB objects has more chance of succeeding than one 2 GB object.
|
|
|
|
|
MicroVirus wrote: Also, the 2 GB per-object limit probably still applies.
Yes it does.
I also find the absense of 64-bit indexers for arrays a bit puzzling. I mean really, it's a freakin' pointer! You mean to tell me you can't have a 64-bit pointer on a 64-bit CPU? I don't think so...
|
|
|
|
|
In my current C# project, I am using an instance of the SerialPort class. I wanted to examine each character as it came in, so I registered a handler for the DataReceived event and set the ReceivedBytesThreshold property to 1. With these settings, I expected that the event handler would be called for each character received but I find that it only gets called once for every 5-8 characters. This is good for communication efficiency, but for what I want to do, I have to loop through the received characters in my event handler. Does anybody know if this is the expected behavior of this class?
|
|
|
|
|
There is an interesting discussion of this question here[^]
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Thanks for the pointer.
--
Regards, Ken
I AM
|
|
|
|
|
I am not surprised, asynchronous receive is a complex process, there are several actors, and some buffers with their sizes and thresholds, some of which one cannot control at all.
You should not be lazy and refuse to loop over the bytes you get in one go, that is pretty easy to accomplish.
It gets really nasty when you have to implement a message-oriented protocol, where the sender sends two or more messages back-to-back, and your receiver unfortunately receives three or more DataReceived events, each covering an arbitrary part of the messages sent (say first half of first msg, then second half+first half of second msg, finally second half of second message).
The only serial receive that goes smoothly is the one that has a fixed message separator (say a NEWLINE) which is guaranteed to appear in between messages and never inside a message (in that case set the NewLine property and use ReadLine). If that is not the case, get ready to collect what you get, whatever amount comes in, then re-packetize it according to your needs.
And then, you should carefully consider whether you need some recovery mechanism, something that helps you out in case some character gets damaged or lost...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
