I'm just trying to make sure I understand. Obviously there is nothing wrong with this but it was my understanding that StructLayoutAttribute was used if the struct were to be passed to unmanaged code, otherwise it wouldn't be necessary. Is there some benefits to using the attribute for managed code as well?
I am trying to access data from the serial port using c# I don't want to use a GUI I just want to be able to recieve a stream of bytes, does anybody know how to do this or have any suggestions thanks Tim
I am trying to play mp3 files from C# app. I have Windows Media Player 6.4 and I am able to play the file but with mp3 files, it disables the fast forward and rewind buttons and I also want the trackbar with it.
So, I installed Windows Media Player 9 with SDK. That has a problem that it doesn't look like the gray color simple WMP and that is the look I want. I know I can change the skin, but that seems to be a lot of work and I don't know how to choose a skin while playing a file !
I did read in help that if I put audio.URL = "c:\filename.mp3?WMPSkin=Compact" it should work, but I didn't see the skin change when I ran the applicaiton.
I developed a system to print our companies invoices. Now, I am trying to find ways to optimize the system. One of the biggest things is how long it takes to print. When a bill is printed, it also prints all the paperwork stored as tiff images that go with that bill. These images really seem to take a long time to print. I tried converting them to a smaller format to hopefully speed up spooling time. Funny enough, it took longer to print a 159KB gif file than a 1344KB tiff file. My question is, does anybody know of a way to decrease the amount of time it takes to print these images? Thanks.
.NET sends _all_ data to a printer using Raster images. This means if you only send plain taxt to a printer, it still converts it into a raster image. If you communicate with the printer via the Serial port it takes quite a while.
If you only want to send text you can develop a component in VB (VS 6.0) that sends plain text to a printer and use this in .NET.
To get the domain name, you can use Environment.UserDomainName. For the username, you can use Environment.UserName. To get the computer name, use Environment.MachineName. If you want more information than this, you can P/Invoke the Network Management APIs. See the API documentation on MSDN at http://msdn.microsoft.com/library/en-us/netmgmt/netmgmt/network_management.asp[^] for more information about the Network Management API.
Although these are not macros they are much more powerful than the MFC equivalents.
The Debug version will only work in the debug build (or any build where you #define DEBUG).
The Trace version is more for instrumented builds where you want the output to go to a log file of the system event log and it is valid to have available in the release build. The Trace version will only work where you #define TRACE.
See also TraceListener
Also, for future reference: In the next version of .NET the Trace classes are meant to be vastly improved.
To add to that, the DefaultTraceListener will output messages you pass to Trace or Debug to the output window when you're debugging your application in .NET. To write to files, the event log, or any custom targets you can use additional TraceListener implementations even at runtime (we use one for error logging in our app).
You're right, though, it is much better than the various TRACE macros, though - as Colin mentioned - a much better trace facility would be nice and is expected. To elaborate, every message you pass is passed to each TraceListener, regardless of whether or not they want to handle it (based on a TraceSwitch setting or other proprietary filtering). This can hamper performance.
Call me stupid, but after coding for 1 year now, I'm going to ask such a trivial question:
Object o; //Where does o fit in memory?
o = new Object(); //Now what? Instantiated? What's that?!
//Work on o somehow; then: o = some_fuction_that_returns_a_newly_created_object(); //Now?
How about the first o that was allocated? I used the same variable to point to two instances (or at least that's what I think) consequently. What happens to the first instance? What about if I want to destroy this o in memory because I simply don't need it anymore?!
Thank you, I appreciate your patience.
"A good friend, is like a good book: the inside is better than the cover..."
profoundwhispers wrote: Object o; //Where does o fit in memory?
It allocates enough memory on the stack for a reference (pointer) to the actual object (what ever it may eventually be)
profoundwhispers wrote: o = new Object(); //Now what? Instantiated? What's that?!
This allocates memory on the heap for the newly instantiated object.
profoundwhispers wrote: o = some_fuction_that_returns_a_newly_created_object(); //Now?
the actual newly created object will be on the heap. o itself is still a pointer/reference on the stack to that object.
profoundwhispers wrote: How about the first o that was allocated? ... What happens to the first instance?
The garbage collector will remove it from the system when it gets around to it, assuming nothing else is referencing it.
profoundwhispers wrote: What about if I want to destroy this o in memory because I simply don't need it anymore?!
If you don't need it anymore just don't reference it. The garbage collector will free the memory when it gets around to it.
One caveat is objects that have a Dispose() method. These usually have resources that the managed heap in .NET cannot garbage collect efficiently. When you no longer need these objects you should call Dispose(). The garbage collector would eventually Dispose it anyway, but it will take a few attempts at it.