|
Override PreCreateWindow() in your child frame class and make sure cs.style includes WS_MAXIMIZE.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
There is a SDI app that I want to shut down after 1 second (it's a frame capture app).
I have tried PostMessage but haven't been able to figure it out yet.
Does anyone have a suggestion ?
Ta.
Elaine ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
The tigress is here 
|
|
|
|
|
PostMessage(WM_CLOSE, 0, 0);
|
|
|
|
|
Yes, but where in the application, remembering that I will need to start a timer ?
The tigress is here
|
|
|
|
|
Check Sleep
or call SetTimer, and you will receive a message WM_TIMER that you need to handle
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
I'm trying to modify the style(CBS_SORT) of a combo box control inside a dialog box at run time. Its seems its not updating? I added the ModifyStyle function inside the InitDialog of the Dialogbox. Is there something I'm missing?
Thanks
|
|
|
|
|
as i tested before, it can not be changed at runtime, may be i (and u) lost something.
my poor solution is:
use 2 combo-boxes, hide one and show one as requested.
includeh10
|
|
|
|
|
I’ve got a .dll from my supplier that I am trying to create a instance of. (I’m not realy good att dll’s).
How may I search for errors when my call to: CreateInstance(…) fails
I know it would return a HRESULT and that the value is 1 on those cpu-s which it don’t work on. The call work properly on my developing machine.
I surely have registered the dll on those cpu-s the call fails.
Pleased for any suggestions…
...and justice for all
APe
|
|
|
|
|
d00_ape wrote:
I’ve got a .dll from my supplier...
Does the DLL's supplier have any suggestions?
d00_ape wrote:
I surely have registered the dll on those cpu-s the call fails.
What about any controls that the DLL uses that might need to be registered?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
The supplier is unfortunately not contactable in about three weeks…
I've checked dependencies using "Dependency Walker" and all seems OK.
...and justice for all
APe
|
|
|
|
|
d00_ape wrote:
The supplier is unfortunately not contactable in about three weeks…
So how about contacting them before the three weeks are up?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
sorry not "in". Ment after...
...and justice for all
APe
|
|
|
|
|
Have you called the CoInitialise(...) before createing the object ?
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
My codeline before is:
//Init OLE
CoInitialize(NULL);
// then CreatiInstance(...)
...and justice for all
APe
|
|
|
|
|
I have set WH_CBT in a dll,problem happened in his call back function:
LRESULT CALLBACK CBTProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if(nCode==HCBT_ACTIVATE)
{
CWnd * pWnd; // Ö¸Õë
HWND hwnd; // ¾ä±ú
DWORD dwNewProcId,dwReturn;
hwnd = (HWND)wParam; // Active Window Handle
pWnd = CWnd::FromHandle(hwnd);
dwReturn=::GetWindowThreadProcessId(hwnd,&dwNewProcId);
pWndActive = pWnd; // µ±Ç°¼¤»î´°ÌåµÄÖ¸Õë
if (dwReturn > 0)
{
if(bFlag)
{
bFlag=false;//bFlag is a global variant
code else; //and initial value is true,but these code
//are executed every times,why? I have no idea
}
}
}
}
|
|
|
|
|
Did you use a shared data segment?
Papa
while (TRUE)
Papa.WillLove ( Bebe ) ;
|
|
|
|
|
You could try putting a breakpoint on bFlag when it is changed. This may show you where the flag is being set to true.
Ant.
|
|
|
|
|
Unless bFlag is in a shared data segment then each process will get its own set of variables for the DLL. So setting it to false only sets it for the current process. Look at http://www.codeproject.com/dll/data_seg_share.asp[^] to see how to create variables in a data segment that is shared between all processes using a DLL.
Mike
|
|
|
|
|
Hi,
Could anyone here recomend a good SDK/Libraries/Sources that will enable me to use IMAP from my application?
I am developing in C++, however I am open to any suggestions.
I have checked componentsource who seem to have a lot of PowerTCP and IPWorks componenets. Is there another site that might have more veriaty?
Thanks,
Jeremy.
Jeremy Pullicino
C++ Developer
Homepage
|
|
|
|
|
i have a c++ sample which generates a active control in exe format, readme says it can be used in VB.
i have no idea how to use it in vb.
if u know VB, please give me a clue for quick start
thx
includeh10
|
|
|
|
|
You mean an ActiveX control ?
I don't know how to use it in VB but try asking at the VB forum.
|
|
|
|
|
in dll.
class a{
CPoint * p;
}
a::a{
p = new CPoint[30];
}
a::~a{
delete p;
}
in exe.
{
A * pa = new a;
delete pa;
}
When the project setting for my application is 'Use MFC in a Shared DLL', there is no problem. But when the setting is 'Use MFC in a Static Library', the compiler gives errors in Released mode, and in Debug mode the .exe is built but this time i face with 'Debug Assertion Failed!'(ASSERT(_crtIsvalidheappoint() ) errors when i run the application.
Thanks for help
|
|
|
|
|
a::~a{
delete[] p;
}You must match forms of new and delete. If you allocated an array, use delete[]. If you allocated a single object, use delete.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
I have done it, but it doesn't help.
|
|
|
|
|
Sorry, I should have read more thoroughly. You shouldn't have one binary in the same process linked to the static version of the C runtime library and another linked to the DLL version. If more than one binary uses the C runtime, they should all use the DLL version.
One of many reasons is that the C runtime creates a new operating system heap (using the HeapCreate function) during CRT startup, for all allocations made using the C or C++ runtime libraries. Each instance of the CRT (a statically-linked copy of the CRT counts as a new instance) creates its own heap. See HEAPINIT.C in the CRT source code.
You can't allocate from one heap but free from another. The effect of your code is that the code from a::a (and hence the memory allocation from new) runs in the context of the code running new a (in this case, your executable), but the memory deallocation runs from the module containing a's destructor (the DLL). delete therefore tries to free the memory from the wrong heap, leading to the assertion. In a Release build, you won't get the assertion, but you will get a memory leak.
The practical upshot of this is that you must either link all MFC-using components in the same process with the MFC DLL, or never create classes outside the DLL they're implemented in.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
