|
logical coords are never dbu. What they are depends on the mapping mode of the DC. See CDC::SetMapMode(). If you do not explicitly set the map mode to something else it will be MM_TEXT and logical coords will be pixels.
Use MapDialogRect() or GetDialogBaseUnits() to convert between pixels and dbu, although I have no idea why you would have to just for displaying a bitmapped background. GetClientRect() will give you the dimensions of your window in pixels.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
Honoured as one of The Most Helpful Members of 2004
|
|
|
|
|
An alternate method to tiling a bitmap over a window is to use CreatePatternBrush[^] to create a brush, and then use FillRect[^] to fill the window. This approach automatically takes into account the size of the bitmap, the window, and so on.
Software Zen: delete this;
|
|
|
|
|
but i don't want to fill, i want to mosaic my bitmap...
thanks anyway for your answer
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
good morning everybody,
As some of you might have sees yesterday, I have some trouble with reactivating an already existing instance of a program of my own which lost the focus.
Mr DavidCrow suggested me to use EnumWindows(), but as i am not familiar at all with CallBack functions, i'd be grateful if some of you post a little example of use of the this functions.
the best would show how to get the handle of a particuliar windows...
thank to all of you
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
|
toxcct wrote:
use EnumWindows(), but as i am not familiar at all with CallBack functions,
With CallBack, You can also use FindWindow and FindWindowEx to Enumerate all Visible desktop Window.
here little Piece of Code to do that:-
BOOL NMPEnumWindows(CStringArray *arWindowsName,CPtrArray *arhWnd)
{
HWND hWnd,hWnd1=NULL;
CString Str;
char lpString[201];
hWnd=::GetDesktopWindow();
do
{
hWnd1=::FindWindowEx(hWnd,hWnd1,NULL,NULL);
::GetWindowText(hWnd1,lpString,200);
Str.Format(\"%s\",lpString);
//select only visible desktop window
If((::IsWindowVisible(hWnd1)==TRUE)&&(Str!=\"\"))
{
arhWnd->Add((HWND)hWnd1);
arWindowsName->Add(Str);
}
}while(hWnd1!=NULL);
return TRUE;
}
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
I need help for two questions , the subject defines the first one.
1)
I created a static splitter window with two horizontal panes. When i click on a particular pane that one becomes active and the other one inactive, which is obvious. But my application requires that only the second one should be active forever. Even if i click on the first pane the control should again return back to the second pane. This may contradict the very idea of using a splitter window, but there seems to be no other option. Can anyone please help?
2)
I use the splitter window so that i can display text in the first pane and display bitmaps (on which i perform image processing operations) in the second pane. Once the text is displayed in the first pane i want it to remain there forever(as long as the application runs). All the operations are to be performed in the second pane without disturbing the first pane.
If anyone can suggest a better way than using splitter windows please let me know.
Thank You
|
|
|
|
|
How to store an HTML page with the use of serialize function of the document class in and SDI applicaition? Any code for that?
|
|
|
|
|
Whenever I do a build, say a Release build, the wrong referenced assemblies (the Debug versions instead of the Release versions) get copied to the target directory. In fact, the Debug versions of the DLLs will get copied to the target directory in both Release and Debug configurations - usually. I can get Visual Studio to reverse this behavior by removing the DLL project refrences and re-adding them while in Release build configuration. Now the Release versions of the dll assemblies will be copied to the target directories during both Release and Debug builds. Does anyone have any idea what is going on here???
Note that, in spite of this weird behavior, when I view the properties for a particular assembly referenced in any given project, the file location is always correct; that is, it will be in the /Debug folder in Debug configuration and in the \Release folder in Release configuration.
|
|
|
|
|
if you want it to overwrite the old link version every time you run a new compile?
Thanks.
William
Fortes in fide et opere!
|
|
|
|
|
Don't know exactly what you mean, but link incrementally off?
|
|
|
|
|
What's the use of that. The compiler will pruduce the same object files for the files that havn't changed. If you change some code the old linke executable will become overwritten automatically!
Blog[^]
|
|
|
|
|
I failed to mention that you have a window remained opened from the previous executable.
William
Fortes in fide et opere!
|
|
|
|
|
If you want to build another executable, you have to close the application (the executable itself if its running). If you really don't want that, than you have to change the compiler / linker output path to a different directory.
Hope this helps
Blog[^]
|
|
|
|
|
I've been programming command window C++ programs for quite a while now. I've gotten my feet wet with both MFC and direct API calls for Windows application programming, but I'm not sure which is better. MFC seems easier to get the interface going, but I'm not sure how to interface all the different controls/buttons etc. The API calls seem like they don't let you do everything that you can do with MFC, but they seem more documented in MSDN. Anyways, which way should I go for professional application development. I don't want to learn something that will be useless when I get a programming job after college.
Thanks!
|
|
|
|
|
CorvetteZ0606 wrote:
Anyways, which way should I go for professional application development.
C#, probably 
Seriously, if you're going to use C++, I'd be more inclined to learn MFC, because it's so much easier that I wouldn't expect anyone to start a project NOT using MFC unless they had a seriously good reason to do so. But I am expecting that the number of people writing Windows apps with C++ will shrink, especially for custom software, as more and more people move to C# or (dagnamit) VB.NET.
However, I think that knowing how a Win32 app is put together is an important skill.
CorvetteZ0606 wrote:
The API calls seem like they don't let you do everything that you can do with MFC
MFC is by and large a lot of wrapper classes around the core API, so I doubt that is the case.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
So you think I should move to C#? I'm not very motivated to do so since I already own Visual Studio 6.0. Also, doesn't an application written in C# require .Net to be installed on the computer to be able to run it? What about computers running OSes like Win 2000 without .Net? Can they run an application I write in C#?
|
|
|
|
|
CorvetteZ0606 wrote:
So you think I should move to C#?
I think if you want to be employable you should at least download SharpDevelop and the .NET SDK and learn some C#. I'm in favour of knowing as much as possible, not putting all your eggs in one basket.
CorvetteZ0606 wrote:
I'm not very motivated to do so since I already own Visual Studio 6.0.
VC6 is crap, you should get VC7, even if you only buy the C++ compiler ( that is actually pretty cheap ). VC6 standard compliance is really bad, and VC7 is amazingly good. The STL implimentation is tons better as well. Finally, you'll find a lot more MFC7 tutorials nowadays, I would have thought.
CorvetteZ0606 wrote:
Also, doesn't an application written in C# require .Net to be installed on the computer to be able to run it?
Yes. this is a much bigger problem in the minds of people who don't use .NET than it is in the real world.
CorvetteZ0606 wrote:
What about computers running OSes like Win 2000 without .Net? Can they run an application I write in C#?
Yes, both XP and 2000 require downloading and installing the .NET framework before a C# or VB.NET app will run on them. In this day and age, how many people have trouble getting a 30 MB file ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
VC6 is crap, you should get VC7, even if you only buy the C++ compiler ( that is actually pretty cheap ). VC6 standard compliance is really bad, and VC7 is amazingly good. The STL implimentation is tons better as well. Finally, you'll find a lot more MFC7 tutorials nowadays, I would have thought.
Try VS2005! This one is great, comes with free express versions (or very cheap) of C++ and C#. Also, you can use winforms and MFC together.
Blog[^]
|
|
|
|
|
The VC++ .NET Express edition doesn't come with MFC.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
 I didn't know that, but that's not a really big problem, since it ships with the beta 2.
Blog[^]
|
|
|
|
|
I have it, but I was talking about stuff that is out now, and anticipating that he didn't want to spend a bundle ( why else lumber yourself with VC6 ? )
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
If you can live with the bugs, the beta is a fine product. It has all the team edition features and it is free.
Besides that, he is a student and students should learn the technology of the future. Not the almost trivial things that were nice to know a lot of years ago..
Blog[^]
|
|
|
|
|
I am an MVP, I had no idea it was freely available ( I get them in the mail ). He should also know that the betas expire in time, he could be locking himself in for something he can't afford.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
He should also know that the betas expire in time
I didn't know that... I'll have to use my account on the MS AA server again
Blog[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
