|
Unless you draw your image in it's exact size (or a multiple of its size) interpolation *must* occur. If you're drawing the exact size, there's no interpolation.
PeterRitchie.com
|
|
|
|
|
Does anyone know of a good reference for this task?
I'm finally able to pull my development head out of the sand and look at the VS 2005 (beta 2), and I was blown away by the added complexity of doing something as simple as putting a few fields on a form (what ever happened to dialogs???) and then display a message. (AfxMessageBox? What's that??????)
|
|
|
|
|
If by C++.net you mean managed C++, I would start with a .NET introduction.
Most of the language-specific aspects of .NET documentation (i.e. books) aren't geared much towards C++--they concentrate on C# or VB.
PeterRitchie.com
|
|
|
|
|
I noticed some very stange values coming back from some calculations in a datatable and decided to investigate.
Has anyone come across the problem below
?CSng(.51) + 0.01
0.51999999046325684
?CSng(.57) + CSng(1)
1.56999993
I assume this is something to do with the way that the floating point value is held, but I've never seen it before.
I'm using VB.NET to do this, but has anyone else noticed similar behaviour in other flavours of .NET? 
|
|
|
|
|
|
Yes, anyone who has done any floating-point calculations on a computer has run into this.
Welcome to floating-point.
PeterRitchie.com
|
|
|
|
|
Hi! I have an app that communicates over tcp/ip. About 50 people use the app and had no problems launching and executing it.But that was this one person in which the program didn´t launch, it just crashed and the error was:
"No Buffer Space Available -- A socket operation could not be performed because the system ran out of buffer space or the queue was full."
This happens i think when i create a new TcpClient and connect to the server.The strangest thing is that this part is inside a try-catch block to get the socketException Exceptions!!!
Any hints on this?The app runs fine on 50 other pc's but this one.Is it from my app or the pc ( I RATHER BLAME IT ON MICROSOFT ). By the way my socket buffer is 1k long, not MB.
Thx in advance.
Never say never
|
|
|
|
|
I HAVE TO MAKE APPLICATION WHICH WILL SERIALIZE/DESERIALIZE THE OBJECT HAVING FILES WITH EXTENSION SUCH AS .GIF, .TIFF.... ETC. AND COMPRESS IT TO ZIP FILES AND TRANSFER TO SERVER... REVERSE IS ALSO TO BE MADE IN THE SAME WAY.... CAN ANYBODY GIVE ME SAMPLE CODE/EXAMPLE ?
PLEASE REPLY ME AT.......... amit29_vjti@sify.com
please give me some idea...THANX![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
Hello hello !
This is my problem : I have created a deployment project and at the end of the installation i destroy all temporary files (which are not required for the good working of my program !).
The fact is after destroying the temporary files, when I run my program through a shortcut (that i put with the visual studio configuration project) the windows installer appears (and run some installation...) before my program appears at last !
Who can explain me this funny thing ?
When i don't destroy my 'temp files', I can run my program through my shortcut without problem !!!
Thank you for explanations.
There is no way to happiness, happiness is the way !
|
|
|
|
|
I assume you are deleting the files in a custom action that runs at the end of the installation?
The problem is that Windows Installer has no way to log the actions that occur in a custom action. So the installer does not know that you intentionally deleted the files, and it triggers the installer service to run automatically in repair mode because it detects a condition - missing files - that warrants a repair.
There are various workarounds, but all require techniques beyond what you can do within Visual Studio.
The only simple solution is to just leave the files on the target machine. This will prevent the installer from starting automatically in repair mode and does not require complex manual modifications of the msi package...
Robert
|
|
|
|
|
Hello Graham,
thank you for your answer !
Finally, I've just integrated the creation of the shortcuts in a custom action and not in the .net setup program itself ! So like this it works well !
I wish you a nice week-end,
bye
alain costanza
There is no way to happiness, happiness is the way !
|
|
|
|
|
Hi all,
Is it possible to use typed dataSets in an application for a pocketPC (Compact .Net framework) ?
I have created an assembly containing an XSD. ("MyApplication.Shared.dll")
I have another assembly containting my bussinesscode. ("MyApplication.BussinessCode.dll")
In the click_eventHandler from a button on my mainForm I call a LoadData method from the bussinessCode assembly, which creates an new instance of a typed DataSet based on the XSD (MyApplication.Shared.MyDataSet myDataSet = new ...)
Next the code loads the dataSet with data : myDataSet.ReadXML("file.xml");
File.xml is a valid XML, based on the XSD.
The problem is that on the moment the click_eventHandler makes the call to the LoadData method I get a System.TypeLoadException occured in System.Windows.Forms.dll (application running on the emulator or on a real device makes no difference, both have the same problem.)
When I remove the codelines using the typed dataSet, there is no exception.
When I launge the exe from windows Explorer on my desktop, the application works correctly.
Any Help ??? 
Greetings,
MPE
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
