|
Yes, I did called RecalcLayout.
I placed AfxMessage in SplitterWnd, so you can see what MFC did before it sent WM_SIZE because the GUI would be sticked until the message box return. I found that the view's size has been changed when the box show. Then after your clicking of OK button, the size of view is restored to the original due to SetColumnInfo/RecalcLayout.
I want to find the first place where MFC change the view's size.
Thank you for replying.;)
|
|
|
|
|
You should only need to respond to WM_SIZE in the frame window class of the window containing the
splitter wnd, something like
void CMyFrameWnd::OnSize(UINT nType, int cx, int cy)
{
CFrameWnd::OnSize(nType, cx, cy);
pSplitterWnd->SetColumnInfo(...);
pSplitterWnd->RecalcLayout();
}
RecalcLayout() will change the view sizes - you don't need to do that (it happens in
CSplitterWnd::OnSize(), where RecalcLayout() is called again).
You shouldn't be handling WM_SIZE in SplitterWnd unless you are sure to call the base class.
You can also try (in the above example code) getting the client rect and calculating the width
of column 0 (clientrect.Width() - desiredwidthofcolumn1) and using SetColumnInfo() on column 0
instead of column 1. That works for me no problems.
|
|
|
|
|
Perhaps only responding to WM_SIZE in frame is not enough, friend.
I have tried the code above at first (certainly in framewnd), but it flash. If you don't believe that, try this code:
void CMyFrameWnd::OnSize(UINT nType, int cx, int cy)
{
CFrameWnd::OnSize(nType,cx,cy);
AfxMessageBox("I am a good man");
pSplitterWnd->SetColumnInfo(...);
pSplitterWnd->RecalcLayout();
}
You will see what happened to the splitter bar. It likes these steps:
1. move from right to left;
2. I am a good man;
3. move back to right(the original position).
So step 1 and 3 made it flash. I want to find out a method that MFC don't move the splitter bar.
|
|
|
|
|
Something else is going on then. I use many splitters and have no problem.
Maybe the flash is the way you are redrawing the view?
Having a message box in the WM_SIZE handler is a bad idea 
|
|
|
|
|
The things are like this: I make an MFC program in Visual Studio 2005, and the program_name.exe doesn't work on a computer that doesn't have the Visual Studio 2005 installed on it (but it does have Visual Studio .NET 2003). How can I make the program_name.exe work on every computer? How do I make an install file for my program?
Thanks
|
|
|
|
|
I am having the same problem.
I have a program created by VS 2003 and then upgraded to VS2005.
There is an error when running on computer that doesnt' have the VS2005.
One thing that I did to solved that problem was downloading DotNet FrameWork 2.0 and its SDK.
http://www.microsoft.com/downloads/details.aspx?familyid=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en[^]
Try it to see if it works for you.
I have the other application using VS C++ 6.0 then I upgraded to VS 2003. Everything is working well on any computer until I upgraded to VS 2005. I am getting the following error message:
"This application has failed to start because the application configuration is incorrect. Reinstalling the application may fixt this problem. "
Same like you.. all the computer has VS2003 but not VS 2005 but I have FrameWork 2.0 installed on those machines. Don't know how to solve that problem yet..
If anybody knows, pls tell me what I should do.
Thanks.
|
|
|
|
|
You need to install the VC2005 redistributables on other computers. Look in %VCDIR%\sdk\v2.0\bootstrapper\packages and you'll see vcredist dirs for the various CPUs. Run the appropriate installer on the other computer.
|
|
|
|
|
You probably compiled with MFC DLLs instead of statically linking. You have two choices:
1) Provide the MFC redistributable files with your app
2) Re-compile your application with MFC statically linked.
If you're not using MFC extension DLLs, there's really no reason to link dynamically.
Consider this
- linking statically to MFC with a basic (minimal) app generates an EXE file of about 250k, but that's the only file you have to ship.
- linking the same app to MFC DLLs generates an app of about 128k, but you have to include additional DLLs that are several megabytes in size.
As the app grows and you use more of the MFC library, it really doesn't matter how you link, but IMHO, the best practice is to avoid dynamic linking if at all possible.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi,
I have a c++ project created by VS 2003 and VB project. They are on intranel network. The application runs OK on network. However, once I upgraded them to VS2005, the application (.exe) doesn't run on the machine that doesn't have VS2005 anymore and I got the error messages saying
Error message for application created by C++
==============================================
"This applicatino has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
Error message for application created by VB
============================================
"Ojbect can't create"
I made the research and found out that in order to run any application, created by VS 2005, on the machine that doesn't have VS 2005 installed, I need Framework 2.0
So I downloaded
Dot Net Framework 2.0 and SDK (setup.exe) (http://www.microsoft.com/downloads/details.aspx?familyid=0856eacb-4362-4b0d-8edd-aab15c5e04f5&displaylang=en[^])
The problem solved for application created using VB but not for C++.
What am I missing? I rearch again.. and found out I need WindowsInstaller 3.1 so I downloaded again and still not working.
Could you please help me what do I need to do so the C++ application will also run on the machine that doesn't have VS 2005 installed.
Thank You.
-- modified at 13:04 Thursday 8th February, 2007
|
|
|
|
|
|
|
What's the exact error message you see now?
|
|
|
|
|
Hi Mark,
I'm getting this error message. My proj was first created in VS 2002, then upgraded to VS2003. No problem on running on any machine. but once I upgraded to VS2005, I got following error message.
Error message for application created by C++
==============================================
"This applicatino has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
|
|
|
|
|
I don't know if this helps. From the docs for the error message:
If a manifest is present in your application but a required Visual C++ library is not installed
in the WinSxS folder, you may get one of the following error messages depending on the version of
Windows on which you try to run your application
|
|
|
|
|
Oh any information is really helpful for me.
And I just looked at it. I think this is it.
I'll try to work out with it and see if I can get it.
^_^ if I stil can't get it, I'll come to to GURUS like you.
Thank you so much Mark.
|
|
|
|
|
Hello
I have an GUI application, which is dependent on a service for few of its features. Whenever the GUI application is executed (for the first time), I install this service and start the service.
Now, if the GUI application is executed in GUEST mode, my application will not be able to install the service and start it, since GUEST mode users are not allowed to install/start service.
So, what i was thinking was to prompt the user for admin user name and password and then impersonate the ADMIN login and install plus start my service and then revert back to GUEST mode.
I wanted to know that how far this approach of mine, i.e. impersonating ADMIN login and reverting back after installing the service is acceptable as per a standard WINDOWS application.
Is it right to ask the user for ADMIN login and password and impersonate it and revert back whenever its necessary ?
Thanks.
|
|
|
|
|
Your post talks about execution of the application, which to me implies that it is already installed. A lot of applications require an administrative user (or a user with administrative rights) to install it. Is this an option for you, so that the service can be install at installation time and set to start accordingly?
Or are you far past that point? :P
Most users are generally not used to having to enter authentication information more than once, much less be asked by an application for the Administrator's authentication information. Some might be suspicious of the application asking for that information. At least, I know that I would.
All that taken into consideration, might be easiest to get the Administrator's information and then use CreateProcessWithLogonW(...) to launch an application that installs and starts the service instead of impersonating and reverting back your own (application's) identity.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
My application is installed on a USB Flash/ Hard disk and directly runs from there, hence it need not be installed on to the PC using administrator rights. So, this isuue of installing the service incase the user has not logged on as Administrator has come up.. can you help me out ?
Thanks.
|
|
|
|
|
Hi,
Now my executable is more than 80 MB.
Is there some recommendations for the size of executable?
Thanks.
|
|
|
|
|
Yes break your file(exe) to dll files
|
|
|
|
|
Is there some recommendations for size and how to do that properly?
Thanks.
|
|
|
|
|
Depends - are you talking about its physical size on disk, or its footprint when in memory?
Converting things like static LIBs to DLLs may actually increase the total size of your end-user distribution, because when you link in a static LIB, you only pull in the functions that you need. But a DLL will contain ALL functions in the library, even if your application only uses 5 out of 80 of them.
If you are talking about your footprint, 80MB may or may not be all that bad, depending on what your application is doing. If it is acting as a database or processing engine, it might not be bad. If it is a fancy text editor working with a 1MB file, it might be.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Actually my application is a scientific application which combine MFC based front end and calculations in Fortran static library. During the run program doing a quite freqent allocations/deallocation of big arrays for the calculations.
And another concern is a project compilation time. It's take a while to compile.
Could you recommend something about it?
Thanks.
|
|
|
|
|
Since you are not building the libraries (they are [preexting] Fortran libraries), you are seeing app build delays. Correct use of pre-compile headers is likely the best way to improve compilation times. Breaking up larger CPP files into small ones can improve build times if you are making code changes, but might not affect release build times. Other than that - no suggestions.
As far as runtime performance, not constantly throwing away allocated memory (keep it around and reuse it as much as possible) is likely your best option. Your users know the kind of application they are using and should expect it to be a bit of a hog at times.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
On top of what James said regarding app performance, if you're app is creating/destroying a lot of threads, consider creating the threads just once, and then just starting them. Creating/destroying threads can cause quite a bit of overhead.
As far as file size, an 80mb file could take quite a bit of time to initially load. You might want to consider breaking the app into DLLs that load when needed the first time, and stay in memory until the app is shut down.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
it doesn't work yet. Don't really know what am I missing. Hopefully the link you give me will give me more information.