|
A quick search with CP's article search engine: [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
trioum wrote: how it is possible
By telling us exactly where you are having trouble: fetching Excel data, or storing data in a database.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
In our project, we have a MFC screen in which tab order is as follow.
Textbox1, Textbox2, combobox1, checkbox1, combobox2, combobox3.
Here tab order works fine upto checkbox1.
Now if my focus is on checkbox and I press tab, focus goes to the Textbox1 instead of combobox2.
If I change me TabOrder as follows, it works fine.
Textbox1, Textbox2, combobox1, combobox2, combobox3, checkbox1.
It means there is some problem with checkbox control.
Please help me to know what could be the issue.
|
|
|
|
|
your tab order is wrong. Re-arrange the tab order. It works fine for me
|
|
|
|
|
Thanks for looking into the issue but I have re-arranged it many time and its not working.
One thing I want to add is that when I Test the screen using Layout-->Test, it works absolutely fine. But when I run the application its not working properly.
|
|
|
|
|
check the properties of the checkbox and tell me if you have checked some of the property values.
i dont see a reason why the tab order will not work if you have provided the tab order properly.
|
|
|
|
|
Visible,TabStop,Auto properties are checked and all the others are unchecked.
|
|
|
|
|
|
Have you read the forum guidelines before posting the query.
And have you worked on VC++ before?
|
|
|
|
|
Dear all,
I am developing an application with VS2008, MFC 90.
There was an exception:0xC015000F: The activation context being deactivated is not the most recently activated one.I can not handle it.
The following is my call stack:
ntdll.dll!7c944a17()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!7c944a17()
user32.dll!7e418734()
user32.dll!7e418bd9()
user32.dll!7e41885a()
user32.dll!7e418822()
user32.dll!7e4189cd()
> mfc90d.dll!AfxInternalPreTranslateMessage(tagMSG * pMsg=0x7e4189f0) Line 242 + 0x14 bytes C++
user32.dll!7e440457()
user32.dll!7e4196c7()
mfc90d.dll!AfxInternalPumpMessage() Line 183 C++
mfc90d.dll!CWinThread::PumpMessage() Line 900 C++
CapsvrTx.exe!CCapSvrRoot::LoadConfig(IUnknown * pICaller=0x00000000, int bRemoteSetup=1, int bMessagePump=1) Line 4716 + 0x20 bytes C++ // this is my function.
Your reply will be deeply appreciated.
Best Regards.
Lance
|
|
|
|
|
Hi Lance,
I encountered the same issue 3 days ago with an MFC based application running on Windows7. I do not fully understand the problem but Junfeng Zhang over at Microsoft has described the situation which causes this error. You can read about it here:
SXS Activation Context --- Activate and Deactivate[^]
I was able to disable the exception by adding the following line in my Applications InitInstance().
afxAmbientActCtx = FALSE;
I do not know if there are any unwanted side-effects by adding this line. I am still researching the this issue.
Best Wishes,
-David Delaune
|
|
|
|
|
Did you ever find more info on this? I'm seeing a similar thing and setting that to FALSE also fixed it for me. Not sure what other side effects that might have though.
|
|
|
|
|
Hi Dave Calkins,
The 0xC015000F activation context error I experienced was easily avoided by adding the following line into my InitInstance() function.
afxAmbientActCtx = FALSE;
I did a bit of research into the subject and discovered that this boolean enables or disables the MFC internal SxS Activation Context[^] switching.
By setting this boolean to false your MFC application Module State Management[^] will not use the Activation Context[^] technologies. Essentially your MFC state management will work about as good as it did in older MFC versions.
Setting the boolean to false will not directly cause any problems. But unfortunately your MFC application loses benefits from SxS. This may or may not be a problem depending on whether your application uses multiple versions of the same library.
Welcome to DLL Hell[^].
Best Wishes,
-David Delaune
|
|
|
|
|
Hi All,
I am facing problem pretty much similar to Lance's one.My application crashes while closing.With a message "The activation context being deactivated is not the most recently activated one.". I tried the solution suggested in multiple replies to this issue, - adding the line afxAmbientActCtx = FALSE; to InitInstance();.But it didn't helped, the crash is still there.I tried to find any unhandled activation context but we do not have any left !!! Although we are saving xml files while closing the application.Any more ideas ? this is how the dump looks like --
> ntdll.dll!776e8b2e()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77733d60()
ole32.dll!75e101e5()
ole32.dll!75e10261()
ole32.dll!75e106fd()
ole32.dll!75dcc969()
msvcrt.dll!772f513f()
msvcrt.dll!772f50cf()
ole32.dll!75dc6cd4()
mfc90.dll!5ced3c82()
mfc90.dll!5ced3b22()
mfc90.dll!5d01e29f()
mfc90.dll!5ce99717()
mfc90.dll!5cedea57()
ole32.dll!75d7aa55()
ole32.dll!75dc6cd4()
mfc90.dll!5ced3c82()
mfc90.dll!5ced3b22()
mfc90.dll!5d01e29f()
mfc90.dll!5ce99717()
mfc90.dll!5cedea57()
ole32.dll!75d7aa55()
ole32.dll!75dc6cd4()
mfc90.dll!5ced3c82()
mfc90.dll!5ced3b22()
mfc90.dll!5d01e29f()
mfc90.dll!5ce99717()
mfc90.dll!5cedea57()
ole32.dll!75d7aa55()
Thanks In Advance
Sumit
|
|
|
|
|
Hi all,
I don't know if anyone is still having this problem, but..
Did any of you tried to figure out what unhandled exceptions occured?
I fixed my problem by switching on ALL Win32 exceptions. Found the issue in just minutes.
In VS 2005 or VS 2008; Debug -> Exceptions... (Ctrl-Alt-E) -> Check the option "Win32 Exceptions" (which enables all options in that branch)
Now start your app in debug mode in VS (Hit the F5 button). Look where it crashes now with an unhandled exception. Its just that simple
Happy hacking,
Albert van Peppen
PS.
The use of "afxAmbientActCtx = FALSE;" should be avoided at all times because it will hide some issues which gonne bite you later on!
|
|
|
|
|
|
Thanks for the info, I appreciate it.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Hey Jorgen,
Din valkomna
|
|
|
|
|
Hi,
With the help of Bacon Ultimate Chessburger
I changed my program or My Control Creation
Logic from ::Create to DDX_CONTROL
DDX_CONTROL in addition to Attaching the
Window object to the CWnd object
Subclass it
After the App Crashed with the Stack Overlow
right after exiting ::DoDataExchage
I went to the "CALL STACK" menu item
and noticed there were a number of calls
to AfxWndProc with message # 15
If I use DDX_CONTROL to Attach an Object
DO I have to provide that Dialog Control
A Message Map entry
|
|
|
|
|
can you paste your code here? you should create your dynamicaly created controls in OnInitDialog, not on DoDataExchange or in OnCreate cause maybe CWnd is not valid in that point
|
|
|
|
|
For the static controls I didn't have a unique
Identfier e.g IDC_STATIC for all my static
controls
DDX_CONTROL(pDX,IDC_STATIC,mycstatic)
DDX_CONTROL(pDX,IDC_STATIC,mycstatic1)
Once I gave each of them a unique identifier
e.g .IDC_STATIC1 IDC_STATIC2
the problem resolved
thankx
|
|
|
|
|
Hi friends,
I want to know why does an application class contain only one object in MFC. Plz tell me.
Thanks & Regards
Sairam
|
|
|
|
|
Because there is only one application in your application...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
In an executable, there must be one entry point that can be called by the loader, runtime etc.
There cannot be any ambiguity here.
That is why we can have only one main function in a console program and only one WinMain function in a windows program. And that is exactly why we can have only one CWinApp or CWinAppEx instance 'cause this class encapsulates the entry point for the executable.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|