|
Christian, I hope you don't mind me cutting and pasting this onto Jyse.com
|
|
|
|
|
I would think you should probably ask Chris.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I've inserted a CDialog as a child of an MDI window with the following code:
m_pDlg = new CMyDlg(FromHandle(m_hWndMDIClient));
m_pDlg->Create(IDD_MYDIALOG, FromHandle(m_hWndMDIClient));
m_pDlg->SetFocus();
m_pDlg->ShowWindow(SW_SHOW);
This works fine however no matter what the title bar stays gray even while I'm actively working inside the dialog.
I reposted this because everyone seemed to be asleep last night when I first posted it. Sorry if you happened to read it twice
Any ideas?
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
AFAIK, only top-level windows can be active. MFC fakes activation for MDI child windows by maintaining an internal active frame, and manually sending WM_NCACTIVATE with the appropriate parameters to the frames. This much i gathered from a quick browse through winfrm.cpp anyway.
If all you care about is getting rid of the gray title bar, you can easily send WM_NCACTIVATE to your dialog to accomplish this; however, you may want to consider using a CFrameWnd -derived class for this purpose, as it will function better along with the other MDI children (CTRL+Tab handling for instance).
Sometimes i only remember, The days when i was young Nowadays no one remembers when they were young and stupid... ADEMA, The Way You Like It
|
|
|
|
|
Sending WM_NCACTIVATE worked!
Thanks,
Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
I have a class CMyDialog derived from CDialog.
How can I create a DialogBar from this class instead of a dialog template resource ?
Thank for attention.
|
|
|
|
|
I was inspired by the STL tutorials. So I thought I would try to use some of it. Nothing complicated, just store some integers in a set<int>. But then when I do this set.find(n) where n=26 it gets an access violation. I remember hearing that STL doesn't do much error checking but really.
Is there something obvious I'm missing? Christian? Anybody?
Cathy
Life's uncertain, have dessert first!
|
|
|
|
|
What does all of the code look like?
are you assigning the result of find to an iterator?
typedef set<int> intSet;
typedef intSet::iterator intIter;
...
intSet ints;
intIter iter;
...
iter = ints.find(26);
|
|
|
|
|
Nope.
The offending line is part of a condition in a for loop:
dcodesUsedByCustoms.find(nDCode)!=dcodesUsedByCustoms.end()
nDCode=26, is a local int.
dcodesUsedByCustoms is a set<int>. It's a static class member variable.
Why do you have any ideas?
Cathy
Life's uncertain, have dessert first!
|
|
|
|
|
I don't know of any apparent problems right off of the top of my head. I tried a small little sample program with a set as a static member varaible and I didn't have any problems. If you can post some code that would really help me help you.
|
|
|
|
|
When I comment out a completely unrelated piece of code it doesn't crash:
aperturePtrsIterator it;
for (it=aperturePtrs.begin(); it<apertureptrs.end(); it++)
="" {
="" (*it)-="">bHaveOutputDCodeDef=false;
}
where aperturePtrs is a class member defined:
vector<codbaperture *=""> aperturePtrs;
and aperturePtrsIterator is defined:
typedef std::vector<codbaperture *="">::iterator aperturePtrsIterator;
There is probably something I'm doing wrong here. I'm trying to store pointers to CODBAperture objects that are stored somewhere else in a linked list type of thing. Does (*it) create an instance of CODBAperture?
Cathy
Life's uncertain, have dessert first!
|
|
|
|
|
If you rule out problems created by your code, perhaps there's a Dinkum library error that has been fixed?
Not that I've ever seen an error like this. My first guess is a bug in your code, overwriting something it shouldn't.
|
|
|
|
|
Mike Nordell wrote:
"If you rule out problems created by your code, perhaps there's a Dinkum library error that has been fixed?"
Thanks for the link! I didn't know about this.
Mike Nordell wrote:
"Not that I've ever seen an error like this. My first guess is a bug in your code, overwriting something it shouldn't."
Yes, I think that's what it is. I commented out a completely unrelated piece of code:
aperturePtrsIterator it;
for (it=aperturePtrs.begin(); it<aperturePtrs.end(); it++)
{
(*it)->bHaveOutputDCodeDef=false;
}
where aperturePtrs is a class member defined:
vector<CODBAperture *> aperturePtrs;
and aperturePtrsIterator is defined:
typedef std::vector<CODBAperture *>::iterator aperturePtrsIterator;
There is probably something I'm doing wrong here. I'm trying to store pointers to CODBAperture objects that are stored somewhere else in a linked list type of thing. Does (*it) create an instance of CODBAperture?
Cathy
Life's uncertain, have dessert first!
|
|
|
|
|
Sorry for the late response.
Cathy wrote:
I commented out a completely unrelated piece of code:
That piece of code is definitely not unrelated, and it's also completely wrong.
You shall never, I repeat never, compare an iterator to any other iterator than for equality or inequality. Even that a vector is to be contigous, there is AFAIK nothing stating that a vector iterator has to be implemented as a pointer to the contents, why something like:
if (it < coll.end())
is incorrect code. It should be
if (it != coll.end())
I'm trying to store pointers to CODBAperture objects that are stored somewhere else in a linked list type of thing. Does (*it) create an instance of CODBAperture?
If your vector only contains pointers to CODBAperture objects? No.
But be aware that keeping pointers to objects in two collections if the one owning the object can delete it during the lifetime of the second referee is obviously inherently dangerous.
|
|
|
|
|
Mike Nordell wrote:
You shall never, I repeat never, compare an iterator to any other iterator than for equality or inequality. Even that a vector is to be contigous, there is AFAIK nothing stating that a vector iterator has to be implemented as a pointer to the contents, why something like:
if (it < coll.end())
is incorrect code. It should be
if (it != coll.end())
Thanks for pointing that out! I didn't notice that one at all.
Mike Nordell wrote:
But be aware that keeping pointers to objects in two collections if the one owning the object can delete it during the lifetime of the second referee is obviously inherently dangerous.
Yes, this was the problem. I was storing a pointer that was no longer valid.
Cathy
Life's uncertain, have dessert first!
|
|
|
|
|
Hi,
Wonder if someone could point me in the right direction, What i want to do is seperate all the User Interface Classes from my processing classes, without using any DLLs.
I envisage doing this through having two projects in my workspace. Does anyone know how i can achieve this. Had a look at Project Wizzard's "Utility Projects", but it doesn't do any build setting to compile.
Cheers
Rich
|
|
|
|
|
It's simple! If you start from scratch, do the following:- Create an empty workspace.
- Create the GUI project. Make it a subproject by ticking on the "part of current workspace" (or something like that) on creation time.
- Ditto for the "processing" project. This sould be of type "static library".
- Go to the settings for the GUI project, look for the "include directories" edit box and add
..\processingProject or whatever the subdirectory for the processing project is named.
- Go to Project -> Dependencies and make the GUI project dependent on the processing one.
- Shake well and serve chilled.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
Shake well and serve chilled.
LOL
I vote pro drink
|
|
|
|
|
Sounds straight forward but i am hitting problems! During links, tried playing around with the /nodefaultlib option, but no luck. Any ideas?
msvcrt.lib(MSVCRT.dll) : error LNK2005: _time already defined in libcmt.lib(time.obj)
msvcrt.lib(MSVCRT.dll) : error LNK2005: __setmbcp already defined in libcmt.lib(mbctype.obj)
LINK : warning LNK4098: defaultlib "mfc42.lib" conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib "mfcs42.lib" conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib "msvcrt.lib" conflicts with use of other libs; use /NODEFAULTLIB:library
Release/pm.exe : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.
pm.exe - 3 error(s), 3 warning(s)
|
|
|
|
|
You have one project setup to build for static linking and the other setup to build for runtime linking.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Is there an easy way to have the CSliderCtl behave the same way when you use the arrow keys as it does when you click/drag it with the mouse? It moves the slider up and down, but how do I trap the message, the CSliderCtl only sends NM_OUTOFMEMORY, NM_RELEASEDCAPTURE, and NM_CUSTOMDRAW. I want the arrow keys to perform the same tasks I do when I handle the M_RELEASEDCAPTURE message.
Ken Goguen
|
|
|
|
|
I haven't tried this myself, but I think it should work:- Derive
CMySliderCtrl from CSliderCtrl .
- add a member variable
int m_pos and handlers for WM_KEYDOWN and WM_KEYUP .
- in
OnKeyDown , store the current position in m_pos . In OnKeyUp , compare the position with the one you stored. If they're different, issue the appropriate NM_RELEASEDCAPTURE with WM_NOTIFY . Check for repeat counts (holding the key pressed) in OnKeyDown for improved results.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Seems to work well.
Thanks,
-kg
Ken Goguen
|
|
|
|
|
I am processing data in a worker thread and calling a member function (of Doc) which performs a file write.
I pass a pointer to CMyAppDoc into the worker thread which I use to access a member function of CMyAppDoc when the thread is created.
The worker thread processes data and stores and stores data in CMyAppDoc using the Doc pointer
pDoc->StorageArray[i] = something;
A little later in this thread when the processing is finished I try to write the data to a file. The function and data are members of CMyAppDoc but the file pointer (myFileFmt) is created within the worker thread. The call is made in the worker thread
pDoc->WriteFmtL15Data(myFileFmt);
The WriteFmtL15 Data does somthing like:
void CLOPCDoc::WriteFmtL15Data(CFile &file)
{
CString sL1("L1"), sL2("L2"), sL3("L3"), sL4("L4"), sL5("L5");
CString tmp("");
for(int a=0; a<=31; a++)
{
tmp.Format(" %d", vecL14[a]);
sL1 += tmp;
}
sL1 += ('\n');
file.Write(sL1, strlen(sL1));
}
When it enters the file writing routine it raises an error:
Unhandled exception in MyApp.exe(MFC42D.DLL): 0xC0000005: Access Violation.
and if I debug the error it bring me to a line in WINCORE.CPP
lResult = pWnd->WindowProc(nMsg, wParam, lParam);
???????????????
|
|
|
|
|
I don't think the problem has to do with myFileFmt being created in the worker thread. To rule this out, you can try (just for the sake of testing) using in WriteFmtL15Data a global CFile object created in the main thread (say in InitInstance ), instead of the one passed in.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|