|
I have trouble with reading unicode file.
StreamReader * streamdata = new StreamReader("FileName",System::Text::UnicodeEncoding);
textBoxBibleData->Text = streamdata->ReadLine();
If I do this, I get
error C2275: 'System::Text::UnicodeEncoding' : illegal use of this type as an expression
stdafx.cpp(0) : see declaration of 'System::Text::UnicodeEncoding'
What's wrong? Furthermore, I put
#using <mscorlib.dll>
using namespace System::IO;
using namespace System::Text;
using namespace System::Globalization;
Someone plz help me~
|
|
|
|
|
System::Text::UnicodeEncoding is a type, but the StreamReader constructor needs an instance. Try System::Text::Encoding::Unicode.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
If I use System::Text::Encoding::Unicode as an argument, there's no compile error. However, if I run the program the program stops.
I think I need to throw an exception. Does anyone have any other ideas?
|
|
|
|
|
Can I access a cookie set by a browser through a winform?
|
|
|
|
|
I don't see why not. They are simply files, located in your user-profile. My IE ones are in C:\Documents and Settings\%myusername%\Local Settings\Temporary Internet Files. (Substitute your own username for %myusername%).
my blog
|
|
|
|
|
I just realized that my application or my controls can receive OnPaint events/calls while my application is in the middle of processing other events. At least I have seen it receive an OnPaint when it is in the middle of processing another OnPaint. That causes problems because the OnPaint processing and the other event processing operate on the same data structures and can trip each other up. Is there any way to tell the .Net framework to queue up the OnPaint and any other similar event/calls and only let them through when my app is not processing any other events? I know that I can build my own queues for this but I would rather not if there is a better way. Would it work if when I receive an OnPaint and I am busy to simply Invalidate() the pea.ClipRectangle or would that just generate another OnPaint event that also didn’t wait until my app was idle. Also if I do have to build my own queues, are there any other calls/events like OnPaint that I have to intercept? Thanks.
Paul Sawyer
|
|
|
|
|
This shouldn't happen unless you're causing a message pump to run within OnPaint. An example might be if you're calling Application.DoEvents.
In OnPaint, you should restrict yourself to only making drawing calls on the current control or form.
In general Windows message processing is not re-entrant.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
The first time I realized I was getting OnPaint calls when I was already busy processing another event was when I opened a modal dialog box in the middle of another OnPaint. I did realize that that wasn’t the brightest thing to do however; I have also seen OnPaint calls come in when I have opened a dialog box from other non OnPaint code. Actually, I was stepping through my (non OnPaint ) code with the debugger. When I step over a dialog.ShowDialog() my main form gets brought to the foreground and draws itself completely as the dialog box is also brought up. So clearly OnPaint calls are getting through there as well. Do you think that I am getting these OnPaint calls as a direct result of opening the modal dialog? IE do I only have to worry about OnPaint calls when I open another form or something? Or is it the case that I can get OnPaint calls anytime the OS or another application decides to draw on top of one of my windows?
I have also wondered if these OnPaint calls could the result of the magic that goes on with the Visual Studio Debugger interacting with my application. IE I wouldn’t have to worry about them in non-debugged execution. Whatever the case, I still need to find a way to stop these OnPaint when I am not ready for them.
Thanks so much for your help.
Paul Sawyer
|
|
|
|
|
The OnPaint override is called when Windows generates a WM_PAINT message for the window (control or form). This occurs when the thread's message queue is otherwise idle (except for timer messages), and there is an invalid region - an area that Windows considers is not up to date.
Parts of the window become invalidated either automatically, as parts of the window that were obscured are revealed (or the window is shown when previously hidden), or explicitly, by calling the Invalidate method. A common way to handle the requirement to update the UI for a control is simply to invalidate the rectangle or region that needs to be updated and allow Windows to generate WM_PAINT when idle.
Another case when painting occurs is when Control.Update is called. In this case OnPaint is called directly [actually indirectly via the window procedure] - Control.Update does not return until OnPaint does.
In the main, though, two conditions are required for OnPaint to be called: an area of the window is invalid, and a message loop is executing.
Modal dialogs have a modal message loop - the code loops, pumping messages, until the dialog is closed. This won't in itself cause the parent form's OnPaint to be called unless an area is invalidated by obscuring and revealing that area.
If you're debugging on the same machine, you may find that the debugger is obscuring the form - when you hit a breakpoint it causes the form to be invalidated; when you run it is revealed so OnPaint is called. You can avoid this by using a smaller debugger window, by putting the debuggee on a separate monitor from the debugger, or by using remote debugging.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Your form will get OnPaint events whenever Windows need the window to redraw itself. In general, this is caused by any other form or application being drawn over your form, or if you resize or move your form at all. You can get the OnPaint event AT ANY TIME and quite frequently. You'll end up seeing the event fire dozens of time per second in the case of a window resize.
Having said that, you, also, can't stop the OnPaint from happening either. Your OnPaint code should do nothing but paint, and paint only what it has to. No dialogs, no data manipulations, no nothing! If you need data to draw the form properly, you should only be doing read-only operations on that data. It might even help, if your situation allows, if you precalculated constant values that your paint code might need. Your paint code should be as small as possible and execute as fast as possible in order to minimize the users perception of sluggish performance.
If youre doing more than painting in your OnPaint code, you really need to rethink your design, what and how your doing, and why you need to do it this way. The events structure is very rigid, with Windows expecting each window event handler to do very specific things. Wander outside of those expectations and you'll end up with very strange, or at the least, very poor behavior/performance.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
You say that OnPaint events can come "AT ANY TIME". Does this include receiving an OnPaint event while your code is in the middle of processing some other event? That is my big question. As I said in my previous posts, I believe that I am seeing the OnPaint events coming when my application is in the middle of processing other events. Mike Dimmick who was also kind enough to answer my question believes that I should NOT be receiving OnPaint events while my application is busy processing other events. Its an important issue because my data structures will not always be in proper shape so that the OnPaint calls can traverse them while I am processing other events. It also surprises me very much that Windows would send OnPaint events while an app is processing other events since I would think that it would lead to sporadic failures for many applications.
Paul Sawyer
|
|
|
|
|
paulsawyer wrote:
Does this include receiving an OnPaint event while your code is in the middle of processing some other event?
YES! But since WM_PAINT is a queued message it won't fire until your windows message pump gets around to calling GetMessage, which won't happen in the middle of an event handler, unless you call Application.DoEvents(), or idle the UI thread somehow.
You should see how many mouse events get fired off just by moving the mouse acrossed your form! The events are not "events" so to speak, but code your write that get executed when certain messages are posted to your window's message QUEUE (hint, hint). There are two types of messages, queued and non-queued. WM_PAINT is a queued message.
I highly recommend reading About Messages and Message Queues[^]
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Thanks very much for the help. I think that I see what is going on. What you and Microsoft say about OnPaint and Event Processing is only half correct. It is true that once I am processing an event, I will not be interrupted with an OnPaint that comes from my application's event queue. However, if I open a dialog box, there is code within the system.windows.forms.dll that will call the OnPaint procedures for any or all of the other controls in my forms while that dialog box is open. What is interesting is that, if my application is busy processing an event, that will prevent it from receiving OnPaint calls that result from actions generated by other applications or Windows. IE if the app is busy, the apps controls will not receive the OnPaint calls that are in its message queue until the application becomes idle. However, it seems to be a completely different story if my app opens a dialog box. Then all of its controls will receive OnPaint calls as is needed to update the controls while the dialog box is open. These OnPaint calls show up in the same Call Stack as my original event and nested "underneath" the original event.
Now that I have sorted that out, I am wondering if there are other calls or class methods like System.Windows.Forms.Form.ShowDialog() that could also cause
OnPaint messages to show up when there are not wanted.
Paul Sawyer
|
|
|
|
|
Hi!!!
I want draw text in .NET Framework control(f.e. System.Windows.Forms.Button),
that text could be located near control border (text of control is located in control
without margine).How can I do it ?
Thanks.
|
|
|
|
|
You can simply do this by setting the TextAligment property from the properties menu ,
I think you will admire it  .
|
|
|
|
|
Thanks LongHC , I know that it is simply to do it by setting the TextAligment to MiddleLeft , but in this case margine remains , but I want that distance between text and control border will equal 0.
|
|
|
|
|
So use onpaint method and override it and then use it's graphics object to draw the text :
e.Graphics.DrawString(and specify here the font and the string and the location);
|
|
|
|
|
I'm downloading VS 2005 Beta 2 as we speak. It must have JUST been placed on MSDN Universal downloads.
|
|
|
|
|
Hi !!!
I have Visual C# project for creating an application for Pocket PC (Smart Device Application), this application uses function call from some unmanaged dll .
For example:
using System.Runtime.InteropServices;
[DllImport("TestDll.dll")]
public extern static void f();
private void button1_Click(object sender, System.EventArgs e)
{
f();
}
Mentioned application deployed to Pocket PC Emulator, and unmanaged dll copied to application folder.But when I run application and try to call function from dll MethodMissingException exception occurs.
Please, help me.Thanks.
|
|
|
|
|
If you wrote the function f in C++, and you didn't use extern "C", its name will have been 'mangled' to encode the type information and calling convention.
You can view what the name actually is by using dumpbin /exports. The dumpbin tool is installed by eVC 4.0 - you'll find a copy in C:\Program Files\Microsoft eMbedded C++ 4.0\EVC\wce420\bin (for example).
You can either use the mangled name as-is by adding the EntryPoint property to the DllImport attribute, or you can add extern "C" to the declaration and rebuild your DLL.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Installed fonts in .NET Compact Framework
Hi all !!!!!
I need system installed fonts in .NET Compact Framework. For .NET Framework it is easy,
f.e.
System.Drawing.Text.InstalledFontCollection installedFontCollection = new System.Drawing.Text.InstalledFontCollection();
System.Drawing.FontFamily[] fontFamilies = installedFontCollection.Families;
but InstalledFontCollection class not supported in .NET Compact Framework  .
Please anybody help me?
Thanks.
|
|
|
|
|
The underlying API is EnumFontFamiliesEx, but I'm not sure this will work for you. You see, it uses a callback function, which itself takes a couple of structures that require advanced layout. Compact Framework 1.0 does not support calling back from native to managed code.
So I think you'd have to write a C++ DLL that wraps EnumFontFamiliesEx with an interface usable from .NET and then call that.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Hi,
in Layout Design,
Is there anyone know the trick, how to put some field(s) into the Page Header Section ?
coz, in every page i wanna show those field(s) shown.
Thank You.
email : sukasukabo@hotmail.com
|
|
|
|
|
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rscreate/htm/rcr_creating_layout_v1_9uia.asp
|
|
|
|
|
Dear friends,
I've an application written in .NET, and ofcourse, in order to run it, we need to install entire .NET framework in the target machine.
Few days ago i came to know about the tool which extracts the minimum dependencies of the .NET application, and as such, we only need to install those DLLs and not the entire framework. The tool was discussed here but i've forgotten about it.
Can anyone tell me about that tool ??
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
