I got one CZoomView sample file form code project.Actually i want zoom fucntion in my applcaiton for every view.In tht,initially when i set scrollposition,extra window is appearing.
For example,in OnDraw(),i set background of window as black
What happended is after execution,when i scroll the horizonatal or vertical scrolls,the window is scrolling more than actual window rect.
More white screen is appearing apart for black background.How can i avoid that? Because while zooming,if user move the scrolls,then extra empty window will appear.i want to avoid that.
There is (I have been told) a way of using an entire dialog template as a resource in another dialog. This would be very usefull in organising things like a property sheet in one corner and something else in another place. Has anyone tried the mechanics of this?
You don't use a dialog template as a resource in another dialog - to me this implies merging. I've never seen this done.
What is common is to:
- define the parent dialog template
- on the parent, define where a child dialog is to be placed by using a dummy control
- in the parent WM_INITDIALOG:
- call CreateDialog*() to create the child dialog from its template
- find the dummy control and it's extents
- delete the dummy and resize/position the child dialog to take its place
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
'W' doesn't need to be L'W' since it will auto-promote to wchar_t.
That should not be true.
It was true with old C++ version, where the wchar_t was not an independent type, and was just a typedef for "unsigned short", and "char" autopromote into "short" and become "unsigned".
In more modern versions, wchar_t can be set up as an independent type with a compiler switch and -now- it becomes a default by standard.
Autopromotion of char-s into wchar-t must not happen, since the "encoding scheme" used in strings may not fit: All negative chars (above 127) are not ASCII and hence may have different meaning if ANSI (depending on the codepage) or UTF (can be UTF-8).
That said, char to wchar_t is not a one-to-one arithmetic conversion. You may have four chars going into a single or a pair of wchar_t (think to UTF-8 to UTF-16 chinese).
That's was what i though when that differentiation was introduced.
But it saved me lot of time form char-type mismatching in strings!
The "werid" thing is that C++ is still taking the old C idea of "char are just numbers" and strings don't exist (there are character arrays and string manipulation functions).
Than wchar_t was introduced, and a type semantic was applied to it.
It would be more correct -nowadays- the case that even char should not have number semantic and a different type (may be byte and unsigned byte, or short short int) should be introduced to represent small integers)
I also wander why C and C++ standard are insisting with all those sort of short, long, long long, long long long, etc. instead of simply define integers as int_x where x is the number of bits (MS does it, but it's not "standard").
Then there might be char_x, incompatible with int_x unless of explicit conversions and functions.
This is more funny I don't know if it's related to the new standards or if not.
My program has a linked list data structure in C++.
is my basic data structure.
I store info along the way from a ComboBox in a Whatever data structure.
Eventually I want to process several of Info and divide them in several Strings.
if (Test->Info[n] == L'/')
//do some processing
I end up getting these errors.
1>main.cpp(686): error C2446: '==' : no conversion from 'int' to 'LPWSTR'
1> Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
1>main.cpp(686): error C2040: '==' : 'LPWSTR' differs in levels of indirection from 'int'
However if I address LPWSTR directly not through the C++ class data structure everything goes smooth as silk.
Yes, I was pointing out what was, not what should be and disagree with you anyway on that point.
char and wchar_t ultimately are just numbers and have no intrinsic meaning on their own--the compiler has no idea what encoding scheme you are using. Is it UTF-16BE, UTF-16LE? Even char doesn't imply what the code page is.