I want to buy a Sony 17'' LCD monitor and I need some help .
First I haven't found much ratings/reviews about this monitor . If anybody has used this type maily for programming please write me .
I have found a sigle review but this is in french . Can somebody translate it?
I would greatly appreciate
le + beau ( vaux mieux pour le prix )
17" 500/1 16ms décoiffant
si vous en avez les moyens achetez-le.
The URL is:
Im writing a C++ program, and I need to add a member variable to a class. This member variable is an object that takes 2 parameters to it's contructor. How do I declare the variable in the header of my class, and initialize it in the constructor of the class that I am using it in?
ROY! Please don't go!
Student of Computer Science
University of Kansas
When you hit the enter key in VS6 it inserts "\r\n" which drops you down a line. This is normal behavior in windows, however I'm editing C++ files that are being used in unix and the \r is an annoyance there.
My question is, does anyone know how to stop VS from inserting the \r -or- Is there a way to run a small script that would strip this out when you save the file?
I don't believe there is a solution in VC6 except to write a little program. (In fact VC6 will take files that have just LF and convert them automatically to CR/LF. By default, VC7 will preserve the original style.)
If you are working with Unix and Windows at the same time, I recommend you installing Cygwin[^].
One of their utilities is u2d and d2u (Unix to Dos/Dos to Unix), which make the conversion you need.
I know that installing Cygwin just for this is overkill, but I think you should give it a try, since it can really ease when you are working with multiplatform code.
It's not the fall that kills you: it's the sudden stop - Down by Law, Jim Jamursch (1986)
We can override OnOk(), or PreTranslateMessage(), but not SetWIndowText() right? What makes a function overridable? Is it that only event handlers are overridable? I'm reading about the word "virtual" but dont see it in the members of say CWnd...like GetWindowTExt etc. I looked in "Input Message Hanfdlers" which has functions like OnHScroll, OnKeyDOwn etdc which are ones that I've seen overridden yet they dont say "virtual" in the declaration (in MSDN)
short answer: you can override any function, in a derived class. but whether your overridden function is called or not depends on who's calling it, what kind of object the caller think he has and the "virtual" option...
i tried to explain it... but realized that this does a better job:
ns wrote: SO having the keyword "virtual" isnt necessary to make a function overridable it seems.
the virtual option affects who calls your override. if you override a non-virtual function, your function will not be called if the caller thinks he's using a base-class object. ie. if the caller only has a CWnd pointer and calls a non-virtual function on your CMyWnd object, he will end up in the base class function, not your override. the effect of the virtual keyword is to allow callers without knowledge of derived classes to call function in the derived class.
Remember that MFC is a thin wrapper over the Win32 API. MFC's CWnd class provides virtual functions that can be overridden in your derived class, as you already know. Some of these virtual functions are actually callback handlers, such as OnSize(), OnGetMinMaxInfo(), etc. They are what get called when a WM_SIZE, WM_GETMINMAXINFO, etc. message is sent/posted to the window.
Now to the interesting part...
MFC provides a back door to allow you to handler *any* Windows message, not just one that's handled by a provided overridable. This is done by the virtual function OnWndMsg(). You can provide custom handling for WM_SETTEXT here. Just be sure to call the base class method for all other messages, or else you could have some seriously weird windowing behavior on your hands!
My program is a small GIS and I was using GDI to display maps and informations. Now I would like to use GDI+ and I didn't find any function to draw a pixel ? Do I have to use GDI to draw pixels and GDI+ to draw the other stuff ?
You can use Graphics.SetPixel, but it is quite slow. You can also use Bitmap.GetData, which returns a BitmapData object, whose Scan0 property is a pointer to the bitmap's data (in BGR format, not RGB format).
"Do unto others as you would have them do unto you." - Jesus
"An eye for an eye only makes the whole world blind." - Mahatma Gandhi
[EDIT]oops, I forgot the correct directory is MSDEV98, not MSDEV.[/EDIT]
The installation probably failed to install VCSPAWN.EXE, which is the program used to control the compiler and linker. Just copy it directly off your CD into the "\Program Files\Microsoft Visual Studio\Common\MSDEV98\BIN\" directory.
Or, if you don't feel like that is a good solution (or the installation is more messed up than just that one file), just reinstall VC6.
You can stash and you can seize
In dreams begin, responsibilities U2 - Acrobat[^]
Stop being PC and accounting for everyone and his momma's timeframe. Just enjoy your - Rohit Sinha in the content-challenged thread
I am a C++ programmer trying to get familiar with VS 7.0 (I have previously been working in 6.0). I cannot seem to get any macro to work in VS 7.0. I had some from 6.0 that I tried to use and I have also tried using samples macros and nothing happens. I get an hour glass for a second or two and then nothing. Is there something I'm not aware of?
The object models changed dramatically between VC6 and VS.NET. I had to rewrite my macros from scratch.
This was less painful than you might think. A number of my macros were no longer necessary. For example, I had one that did a 'find and replace' in all of the open documents. That functionality is builtin now.
I am experiencing extremely slow performance when using the MFC CBitmap::CreateCompatibleBitmap() and CDC::BitBlt() to copy compatible bitmaps between device contexts. Sometimes the calls are extremely fast, as expected from the wealth of documentation that recommends using memory bitmaps to optimize graphics. However, they are frequently slow, meaning that a single call to the either method takes approximately 0.5 seconds (sometimes more), which is obvious to our applications’ users.
I need to understand why some calls to these two methods are so slow and what we can do to prevent this from happening.
The zip file I have attached contains a DevStudio 6.0 MFC application with a few lines of code added to show the problem.
1) Run the application.
2) Resize the view - larger windows fail sooner.
3) Use File/DC Test to bring up the test dialog
4) Press the Blit button repeatedly, and look at the time reported in the message on the dialog. After a while, it will suddenly be much slower.
The application stores a number of CDC's and CBitmap's that are all the same size and compatible with the CView's CDC. On the first blit button press there is one CDC/CBitmap pair, then two on the second, etc. Each time the button is pressed, the old CDC/CBitmap's are destroyed, and new ones are created. The first CDC is BitBlt’ed to the second, the second to the third, etc, and finally the top CDC is blitted to the screen. Basically, this is done in two simple functions, controlled from the dialog callback:
CDeviceContextBufferCollection::CreateBuffer() - 5 Lines of Code
CDeviceContextBufferCollection::Copy() - 7 Lines of Code
CDCDrawer::OnBlit() - < 20 Lines
All the other code is for house keeping, and there is not much of it. The application was created with the MFC application wizard and is largely unchanged.
The times for each method are measured using a high performance timer, and are shown on the dialog. The time for each BitBlt() is also measured and sent to the TRACE window and can be seen when debugging.
For the first few executions, both calls are fast. However, at some point their performance will degrade. The trace output will show that some BitBlt()s are still very fast and some now are very slow. Note that all of these timed BitBlt()s are from one memory bitmap to another (i.e. not to the screen) and all the CDC's and CBitmap's are compatible (i.e. there are no DIBs).
With the application Maximized, trace window output:
BitBlt took 741.828920ms
BitBlt took 38.999929ms
BitBlt took 14.086707ms
This shows that one BitBlt() took almost 3/4 seconds; the other two were quick. The first one (the slow one) is copying between two memory bitmaps; the new one is also two memory bitmaps, but is faster, and the last time, which is the fastest, is between a memory bitmap and the screen.
With a smaller window more bitmaps have to be allocated before it fails:
BitBlt took 0.016483ms
BitBlt took 0.016483ms
BitBlt took 0.012571ms
BitBlt took 0.012292ms
BitBlt took 0.011733ms
BitBlt took 0.012013ms
BitBlt took 0.012013ms
BitBlt took 0.011733ms
BitBlt took 0.012013ms BitBlt took 246.562622ms
BitBlt took 10.034516ms
BitBlt took 2.872153ms
Again, there are lots of fast BitBlt()s and one very slow one; BitBlt()ing to the screen remains fast at 3 ms.
Once a particular BitBlt() is slow, then copying between that pair of CDC will always be slow. This behaviour is not really shown by the test application, as the CDC's and CBitmap's are destroyed and recreated on each iteration. Once a 'slow' CBitmap has been allocated, then next one allocated will often be slow too, sometimes is fast.
These times are typical on my machine, when it has just been rebooted, and Task Manager shows memory usage at around 100Mb (on the 512Mb machine). Hence I do not believe it is memory fragmentation/virtual memory issue. When the CView is not maximized, each CBitmap is relatively small (< 1Mb) so allocating 20 or so should not be a big deal. The same issue is seen on a variety of machines / OSs, and general older machines fail sooner. When the performance is good, Task Manager does not register any CPU usage; as soon at it is bad, CPU usage goes to 100 %.
The same application has been run on several other computers. I discovered that the behavior is slightly different between the different machines. Some machines had the CreateCompatibleBitmap() method being always fast and the BitBlt() degrading in performance. Other machines had both methods equally bad.
The real application requires several memory bitmaps to optimize z-layer drawing, more than two. Our simple test application gives poor performance when two are allocated. Using memory bitmaps and compatible CDC's is described everywhere as a method of gaining good performance. What are we doing wrong?
I agree, However in the deep dark recesses of the peanut I call a brain I seem to remember you could access the other class by offsetting the class A pointer by some amount. The classes are stored contigously in memory. I just can't remember the details.
A working Program is one that has only unobserved bugs
I thought I wanted a career, turns out I just wanted paychecks
B *b = static_cast <B *> (static_cast <C *> (this));
This assumes this is a pointer to A.
You do have to remember that in theory, this is very unsafe since it assumes that the member function is in fact being invoked from an instance of C. However, as long as that is the case, it works perfectly well.
I'm going to patent thought. I have yet to see any prior art.