|
I have a Windows Form system which has been in development for about a year. In the VS 2000 platform we incorporated a number of System.Diagnostic.Trace.WriteLineIf statements to trace behavior between the client and the remote communication library it connects with. In the production environment then, one can run the app with the /Debug switch fed into it and we can see what is occuring and which model it bombed on.
All worked great and it was becoming a quick selling point to the developers since this tool would become used by both them and the business analysts.
Now comes VS 2003 and a few weeks ago I got my new laptop and my new install of VS 2003. Woohoo. But when I ran into a situation, and wanted to debug it, the dbgView viewer sat quietly. 
We ran a very simple test just a few minutes ago:
I constructed a C# console app.
I have my Main issue a Console.Write, a Trace.WriteLine, and a Debug.WriteLine. Only the Console.Write appeared anywhere!!! 
Finally....we created a direct hook into the debug writer with DllImport and added that to the list of outputs. Voila, the raw debug writer created the message without problems. 
am I going crazy or is there a 1.1 bug that wasn't there in 1.0??? 
The application test:
using System;
using System.Runtime.InteropServices;
using System.Diagnostics;
namespace Bomb
{
class Class1
{
[DllImport("Kernel32.dll")]
static extern void OutputDebugString(string msg);
[STAThread]
static void Main(string[] args)
{
Console.Out.Write("This is a test");
Trace.WriteLine("This is a test");
Debug.WriteLine("This is a test");
OutputDebugString("This is a freekin test");
Console.Read();
}
}
}
_____________________________________________
Of all the senses I could possibly lose,
..oh the hell with it! This problem is making me loose my sanity.
|
|
|
|
|
This has to do with TraceListener implementations. The DefaultTraceListener is added to Debug.Listeners and Trace.Listeners by default. VS.NET's Output window will show these messages using the DefaultTraceListener, but the Console won't (and never did, unless you had your console set up as a debugging output device for the OutputDebugString API). I'm sure you knew this, but I include it for posterity (since this is a community forum).
Are you running this test application in VS.NET 2003 or in a new instance of the command shell?
Finally, make sure your application actually adds that TraceListener implementation. Perhaps when you recompiled / ported your code to .NET 1.1 some things got misplaced / forgotten?
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Heath,
Heath Stewart wrote:
I'm sure you knew this, but I include it for posterity
Yeh...the Console.Write was just to flag we were entering the code that would generate the trace messages.
After doing more testing we discovered that it is a change in how VS implements the TraceListeners. In VS 2000 -- your trace messages went to the Output window -- but apparently it was also acted as a pass-thru so that such debugging windows as DBGView would see the messages as well.
In VS 2003 the TraceListener deployment traps the trace messages and limits them to only the VS window. As a result, when I look at the viewer window I see no trace messages. However, when I run the executable outside of VS2003 and run DBGView, I see all of my trace messages as expected. (I'm not in the habit of staring at my VS Output window!)
This behaviour was a bit disconcerting since DbgView was the main debugging tool we were using to see debug trace messages coming from our remote component library.
A departure from the normal behaviour, often causes a developer to wonder if this is a bug instead of a feature. 
_____________________________________________
Of all the senses I could possibly lose,
It is most often the one called 'common' that gets lost the most.
|
|
|
|
|
Actually, I think you mean VS 2002.
Anyway, I looked at the IL for the System.dll assembly and see that the v1.1.4322 of the DefaultTraceListener still uses the OutputDebugString API. I'd be willing to guess that installing VS.NET 2003 somehow screwed up some settings that register DbgView as a valid debugger in Windows.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hi,
is there any simple way to set a CPropertySheet's background color? for example to black or anything?
and the other q is how can you do the same with the CTabCtrl?
thx in forward...
|
|
|
|
|
Wrong forum. Try the Visual C++ forum. This is the C# forum - a language targing the CLR, part of the .NET Framework.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hi
I am working on building a C# library where I need to read an image (a JPEG disk file) into a string for further manipulation.
The image has been read into the variables as long as I read it into either byte[] or char[]. But When convert the byte[] or char[] into a string ( by appending each byte or char) I have found that most of the non printable characters are converted to some junk.
Can anyone has a solution on reading an Image (binary data) into a string and retain its original data intact.
thanks
AliIMCIn
|
|
|
|
|
You can encode your bytes as Base64. I'm not sure if .net framework has the ability to do that, but you can easily do that.
Here is an article that describes it: http://www.kbcafe.com/articles/HowTo.Base64.pdf
|
|
|
|
|
.net has base64 encoding:
byte[] data = ...;
string jpgData = Convert.ToBase64String(data);
to convert back to bytes
byte[] data = Convert.FromBase64String(jpgData);
|
|
|
|
|
You can also use the ToBase64Transform and FromBase64Transform, which are a little more stream-friendly. These can be found in the System.Security.Cryptography namespace. The Convert class is okay when you're dealing with small buffers, but potentially large buffers like would be required for images you'd want buffer when possible. For instance, when sending data like this across the wire, you could buffer the bytes to a NetworkStream, transforming the byte[] array to base64 and sending that across the wire (also see Encoding to send this transformed byte[] buffer in the encoding of your choice, like UTF-8 for "application/x-www-form-urlencoded" MIME for an HTTP POST).
See the FromBase64Transform constructor in the .NET Framework SDK for an example.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
See if this is what you want:
System.IO.FileStream stream = new System.IO.FileStream("Image.bmp", System.IO.FileMode.Open, System.IO.FileAccess.Read);
byte[] buffer = new byte[stream.Length];
stream.Read(buffer, 0, (int)stream.Length);
stream.Close();
string str;
for(int i=0;i<stream.Length;i++)
str += buffer[i].ToString()+" ";
Mazy
You're face to face,
With the man who sold the world - David Bowie
|
|
|
|
|
 No, use base64 encoding. See the replies above. Coming up with your own encodings will kill you in the end because nothing else will understand your encoding so it can't decode it. Besides, this will create unnecessary string parsing (you'll have to parse each space-separate integer and convert that to a byte before you can even create your buffer, not to mention that it'll take an extra parsing process to even figure out how big the buffer should be).
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Ok. 
Mazy
You're face to face,
With the man who sold the world - David Bowie
|
|
|
|
|
Hi
Can any1 tell me how I can print "UnPrintable" ASCII characters in a Textbox ???
raheel
|
|
|
|
|
If they aren't "printable", then they'll be displayed as square boxes (typically). Either way, you must escape the characters. For the Unicode character set (which .NET uses internally for strings), you can use "\uXXXX" - where each "X" represents a hexidecimal value - with the Unicode character (which could be in the ASCII range, such as "\u000a" for the line feed (decimal value 10). You can also use "\xX" - where "X" is a variable number of hexidecimal values - like "\x0a" (decimal value 10), which is also the line feed. Depending on other properties in your TextBox, these might in fact insert line feeds and tabs.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
hi,
i want to append a tsruct every x seconds to a binary file, but i don't get it.
here is the code of the struct:
<br />
public struct abc<br />
{<br />
public DateTime abcDate;<br />
public float abcFloat;<br />
}<br />
how can i append this struct to a binary file?
Thanks,
Dennis
|
|
|
|
|
Open the binary file into a Stream (or a derivative, like FileStream) and write the two members. You don't need to include a header if the struct fields are fixed-width (the DateTime field is always 64 bits if you use Ticks or 32 bits if you use Milliseconds, and the Single (float) is always 32 bits). If you use a BinaryWriter (can take the Stream you opened as an argument), you can use the overloaded Write method to easily write these fields:
FileStream stream = File.Open("path.bin", FileMode.Append, FileAccess.ReadWrite, FileShare.Read);
BinaryWriter writer = new BinaryWriter(stream);
while (false)
{
abc val = new abc();
val.abcDate = DateTime.Now;
val.abcFloat = 1.0f;
writer.Write(val.abcDate.Ticks);
writer.Write(val.abcFloat);
Thread.Sleep(1000);
}
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks a lot, seems to work!
I'm still not quite sure if it's running ok, because i don't get the bytes out of the file correct. How do i have to assign the bytes to the datetime ?
Thanks,
Dennis
|
|
|
|
|
You don't read the bytes directly, unless you want to take all the Types into account. Use a BinaryReader and call ReadInt64 to get the ticks or ReadInt32 to get the milliseconds. Next, read the struct documentation for DateTime in the .NET Framework SDK. There are several constructor overloads, some of which accept either the ticks or milliseconds.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hi.
How can i prevent a user from changing tabpage without removing tabpages and without the flicker that occurs if i in the selectedIndexChanged event set it back to the original tabpage?
It seems that all events a raised AFTER the tabpage changed.... even the various mouse events...
|
|
|
|
|
Yes, of course it's called after. It is SelectedIndexChanged afterall.
In order to prevent this, you're going to have to derive from TabControl and override WndProc and handle the TCN_SELCHANGING (-552). Return true to prevent the change:
private const int TCN_SELCHANGING = -552;
protected override void WndProc(ref Message m)
{
base.WndProc(ref m);
if (m.Msg == TCN_SELCHANGING)
{
if (!allowChange) m.Result = new IntPtr(1);
}
}
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Forgive me, but I'm a little confused.
Heath Stewart wrote:
private const int TCN_SELCHANGING = -552;
I'm assuming that's from CommCtrl.h :
#define TCN_FIRST (0U-550U) // tab control
...
#define TCN_SELCHANGING (TCN_FIRST - 2)
But the MSDN library has the following definition for WindowProc:
LRESULT CALLBACK WindowProc( HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam
);
Which leads me to believe that uMsg will never be -552.
To test it, I derived a control from TabControl and overrode WndProc as such:
protected override void WndProc(ref Message m) {
Console.WriteLine(m.Msg);
base.WndProc (ref m);
}
I added my tab control to a form, gave it a few tabpages and ran it. Sure enough, every value printed as I clicked and poked and prodded was a positive integer.
I started programming with .NET, so I don't have any prior experience with windows messages and I'm obviously missing something, but I can't figure it out. I've been searching the documentation for the last hour trying to make sense of it, with no luck.
|
|
|
|
|
The fact that the number looks negative to you doesn't mean it's negative to a CPU. The runtime doesn't really care, either, except when it comes time to compare or display the value. The Type of the value type will determine if it can be negative or not.
A 32-bit signed integer such as -552 is the same as the 32-bit unsigned integer 0xfffffdd8. When taking into account unsigned equivalents, this is 4294966744.
Unfortunately, this only would've applied if the const was defined as a UInt32 (uint keyword). Sorry about the confusion. Instead, define your constant int as the hex value given above and it should work.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Please forgive me if I'm being exceptionally dense, but it's still not clear to me.
Heath Stewart wrote:
A 32-bit signed integer such as -552 is the same as the 32-bit unsigned integer 0xfffffdd8. When taking into account unsigned equivalents, this is 4294966744.
Thank you for explaining this. This part makes perfect sense to me, that's not the problem.
The range for TabControl messages, according to CommCtrl.h is -550 to -580. None of the value I get from my tab control is even close to this range. Switching back and forth between pages, selecting controls on the pages, hiding and showing the form... all of them return message IDs of 0-675
Heath Stewart wrote:
define your constant int as the hex value given above and it should work.
I can't do this because 0xffffdd8 is beyond the valid range of values for an int. Using a long or unit would be pointless because the Msg poperty of Message is of type int.
const int TCN_SELCHANGING = -552;
protected override void WndProc(ref Message m) {
Debug.Assert(m.Msg != TCN_SELCHANGING);
base.WndProc (ref m);
}
|
|
|
|
|
It wouldn't be pointless to define a uint because you can always cast it to an int upon comparing, but I wouldn't recommend it since this method should be fast (it has to process potentially a lot of messages, after all) and the extra instruction to cast (and possibly two more to store and retrieve depending on the code) is too expensive.
Fortunately, I re-read the documentation for TCN_SELCHANGING and noticed that this message is sent in the form of a WM_NOTIFY message to the parent of the TabControl. This little example works:
using System;
using System.Runtime.InteropServices;
using System.Windows.Forms;
public class Test : Form
{
public static void Main()
{
Application.Run(new Test());
}
public Test()
{
TabControl tab = new TabControl();
this.SuspendLayout();
this.Text = "Test";
this.Controls.Add(tab);
tab.TabPages.Add(new TabPage("Page 1"));
tab.TabPages.Add(new TabPage("Page 2"));
tab.Dock = DockStyle.Fill;
this.ResumeLayout();
}
private const int WM_NOTIFY = 0x004e;
private const int TCN_SELCHANGING = -552;
private struct NMHDR
{
public IntPtr hwndFrom;
public int idFrom;
public int code;
}
protected override void WndProc(ref Message m)
{
base.WndProc(ref m);
if (m.Msg == WM_NOTIFY)
{
NMHDR hdr = (NMHDR)Marshal.PtrToStructure(m.LParam, typeof(NMHDR));
Console.WriteLine(hdr.code);
if (hdr.code == TCN_SELCHANGING)
m.Result = new IntPtr(1);
}
}
}Sorry for the mess. Most messages I deal with are sent directly and aren't WM_NOTIFY style messages. This gets a little quirky. You'll notice I marshal the LPARAM parameter to an NMHDR struct, which I then check the code. Getting to know the notification messages helps, I just feel dumb that I didn't fully read it before.
Also note that I'm calling base.WndProc first. If you don't, Windows is likely to change the Message.Result field to 0 (or reset it to 0). You could also just not call it and return in this case if you get the WM_NOTIFY message with the NMHDR.code set to TCN_SELCHANGING.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
