I'm developing a part of a larger System where I'm using the crystal reports
viewer that comes with Visual Studio .NET.
I want to be able to control wether or not the printer selection screen
should be displayed.
In our System we already have configured wich printer to use, so the windows
printer selection screen that appears after pressing the print button,
should not be shown.
Is this at all possible to control when I'm usig the crystal reports viewer?
If you use the ildasm.exe IL disassembler that ships with the .NET Framework SDK and view the IL for CrystalReportViewer.PrintReport - following it till ReportDocumentBase.Print - you'll see that it displays the PrintDialog without checking any state variables. So, unfortunately, you can't change this behavior.
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.