|
I want implement full screen mode in my small application. I wrote codes
as follows:
cx =
cy =
SetWindowPos (hwnd, NULL, -4, -4, cx, cy, SWP_NOZORDER | SWP_FRAMECHANGED);
They work pretty well, the minor boring thing is that the task bar (if Not
autohide) is still there. it will not disappear unless I click it once? any
solution? thanks, thanks.
http://ihome.ust.hk/~zhaoming
|
|
|
|
|
Siuming wrote:
SetWindowPos (hwnd, NULL, -4, -4, cx, cy, SWP_NOZORDER | SWP_FRAMECHANGED);
Make that :-
SetWindowPos (hwnd, HWND_TOPMOST, -4, -4, cx, cy, SWP_NOZORDER | SWP_FRAMECHANGED);
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
Very close Nish, but if you want to make the window topmost, you have to drop the SWP_NOZORDER flag
---
CPUA 0x5041
Sonork 100.11743 Chicken Little
Within you lies the power for good - Use it!
|
|
|
|
|
|
Many Thanks! It works!
goal
|
|
|
|
|
Hi,
I have been trying the same thing,But my window is not shown properly.
In my code
cx=GetSystemMetrics(SM_CXFULLSCREEN);
cy=GetSystemMetrics(SM_CYFULLSCREEN);
Regards
Neha
|
|
|
|
|
Dear,
What I've used are:
<br />
int cx = GetSystemMetrics (SM_CXSCREEN);<br />
int cy = GetSystemMetrics (SM_CYSCREEN);<br />
int cyCaption = GetSystemMetrics(SM_CYCAPTION);<br />
int cyMenu = GetSystemMetrics(SM_CYMENU);<br />
SetWindowPos (hwnd, HWND_TOPMOST, -4, -(cyCaption + cyMenu + 4), screenx + 8, screeny + (cyCaption + cyMenu) + 8, SWP_FRAMECHANGED);<br />
|
|
|
|
|
Hi,
I've recently installed .NET and is familiarizing myself with it right now. With
the common-runtime and C# is C++ getting less love from MS? I've been developing
with VC6.0 for some time now and I like it ok, but the .net release seems
to be moving in a general direction away from c++.
I am just wondering about the future of my favorite language?
Is the future with c# now? Or is it managed c++?
Is MFC or ATL based apps outdated now?
In essence, I'm wondering what I should focus on in the .Net world?
faust
|
|
|
|
|
I say learn C# but don't bail on C++. For starters, they have put a lot into standards compliance, with more to come, and that has got to be a good thing.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
|
|
|
|
|
I agree about the standards compliance. That is a good sign.
Thanks for the advice, and I think I'll follow it and learn c#.
I'm still interested in more comments from others as well.
|
|
|
|
|
My strategy for developing .NET applications is to use C# for the UI and database handling and use managed C++ for the system calls and stuff that the Framework doesn't support (such as TAPI, MAPI)
Michael
Logic, my dear Zoe, merely enables one to be wrong with authority. - The Doctor
|
|
|
|
|
|
That sounds like a nightmare to maintain though
And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.
|
|
|
|
|
For me C# is Microsoft answer to Java, I don't like and don't want to use C#. There will be enough room for C++ in the future too.
The problem is that the main C++ compiler is VS and that we all love VS, but should the MFC give up I'm sure there will be some replacement library - that library could generate CLR or else I don't care, I just want to code C++.
You see you're not alone
Yarp
|
|
|
|
|
Nice. Still what Microsoft says and does is quite
important. I still need to make livelihood, even if it
means C#. As long as I don't ever need to use VB again,
I follow the money.
Still it would be nice if some of all this effort
had gone into providing better libraries and standard
conformance of c++ earlier, that way I don't think
there would have been the same "need" for C# or Java.
But who knows?
|
|
|
|
|
As you say the final word is Microsoft.
But they still have to consider our position and reality.
I know some companies who ran Java projects and suffered many dispointements. At the moment C# is much too young to be compared to this experience and I think we can rely on Microsoft to make it a good Microsoft solutions integrated product, but time will do the rest.
I hope C++ will win.
Yarp
|
|
|
|
|
We both know this question you're asking is ahead of its time. Don't forget why Microsoft came up with C# in the first place. What happens if the "common-language runtime" doesn't prove itself practical in the long run?
In other words, and as a personal opinion, I would not consider anything else other than already-based lanuages (C, C++, VB, etc) for long-term projects.
In any case, you could always ask yourself a few questions before deciding to develop something in C#:
1. Do I really need the common-language feature? In other words, are there any other language involved in this project - even as a 3rd party module?
2. If C++ is a pain in this case, why not use VB or managed C++, or Java? Something that surely works on my customer's computers without installing new runtime libraries... What will C# give me that they won't? Is it performance, low maintenance, etc?
Look, it's not that I have anything against C#, or any other language for that matter. It's just that experience shows that these new initiatives are sometimes rendered obsolete by other initiatives after a relatively short time. The few exceptions are C and C++. So your customers will be more happy to know that their product is based on something solid. That's the most important issue in my opinion.
/=/=/=/=
Deus
/=/=/=/=
|
|
|
|
|
the function to get all char in keyboard is GetKeyboardState.what is the function to know whether ctrl or shift is pressed.Also can u tell how to get the mouse events
|
|
|
|
|
if (GetKeyState(VK_CONTROL) & 0x8000)
{}
If (GetKeyState(VK_SHIFT) & 0x8000)
{}
If (GetKeyState(VK_LBUTTON) & 0x8000)
{}
...
http://ihome.ust.hk/~zhaoming
|
|
|
|
|
I have some troubles with MFC DLLs that contain resources.
First of all, I would like to know which MFC DLL project I have to choose exactly (Regular DLL or MFC extension DLL). And what about their differences ?
My problem is : when I have a resource (for example a Dialog) in my DLL which has the same Res ID that an another resource in my EXE, and when I want to show one of the two, I may have the other being displayed (because of the same ID). So currently I must compare the 2 "resources.h" to not have similar IDs which is not a great solution to my problem.
Please help me !
jpeg
|
|
|
|
|
Hi,
The general bahavior is to use the dialog resource of the dll inside the
dll only(or the dialog is instatiated inside the dll). Then MFC actually
takes care of locating the resource from the correct module autmatically.
(But you need the 'AFX_MANAGE_STATE(AfxGetStaticModuleState( ));' )
If your are deviating from this behavior then you need to get the
'resource handle' of the module from which you want to use the resource
by using FindResource and passing the desired module handle and then
use the returned resource handle to load the resource and
use it,.
|
|
|
|
|
Thank you for your answer but I think my question wasn't clear enough.
In fact, I have got a method in my DLL which aims to show a dialog. For example :
void myMethod()
{
CMyDialog dlg;
dlg.DoModal();
}
the CMyDialog class was done with the ClassWizard after designing the dialog itself.
So I compile my DLL and all is OK.
Then, I create a new WIN32 EXE project. I include my dll.lib in the Project settings and in my code I include the dll.h which declares the dll's methods and functions. In this code, I try to show the dll's dialog by calling myMethod().
I compile and all is OK but when I execute the EXE, instead of displaying the DLL's dialog, it displays another resource contained in the EXE because its resource ID is the same of the DLL's dialog ID.
Thank you for your help.
|
|
|
|
|
How abt using the
'AFX_MANAGE_STATE(AfxGetStaticModuleState( ));
at the start of the function as I have mentioned in
my previous post ?
|
|
|
|
|
OK, thanks a lot ...
I see you're very good in visual C++ programming so I've got another question : Can you explain me exactly what are the differences between the MFC Regular DLL Project and the MFC Extension DLL Project ? When should I choose one instead of the other ?
|
|
|
|
|
In MFC extension Dll's you can export classes,
but there is a draw back, you need to use these
dll's only in C++ code(not even 'C', uses explicit
C++ linkage).
Where as a regular Dll you cannot export classes,
only functions ! but a properly designed & written
dll can in general be called from many
language like C,C++, VB etc....
|
|
|
|