|
Do a PostMessage with WM_CLOSE - PostMessage(WM_CLOSE, 0 , 0)
|
|
|
|
|
use a CTimer for the "period of time" and then ... exit(0); 
~RaGE();
|
|
|
|
|
main()
{
Sleep(TIME);
exit(0);
}
/Magnus
|
|
|
|
|
Now that is what I call a usefull program! 
Roger Allen
Sonork 100.10016
If I had a quote, it would be a very good one.
|
|
|
|
|
Sure. Zillions.
Here's a frighteningly unfriendly way; it hangs a sword of Damocles over
the process:
~~~~~
// the basic killer thread
DWORD WINAPI _MySleeper(LPVOID msWaitPeriod)
{
Sleep((DWORD)msWaitPeriod);
TerminateProcess(GetCurrentProcess(),0);
return 0;
}
// hang the sword
DWORD ThreadId;
DWORD ms=10*1000; // 10 seconds
CloseHandle(CreateThread(0,0,_MySleeper,(LPVOID)ms,0,&ThreadId));
~~~~~
Now that process has 10 seconds to live.
It'll suffer a brutal death, probably leaving leaving lots of
open resources improperly closed. 
Better to just set a flag, and post a quit message during idle
or something.
|
|
|
|
|
I am having a problem getting intellisense to work with the header files for my libraries. I thought that all you needed to do was add an include path for the location of my header files and away you go but that doesn't seem to be the case. All intellisense will recognise are macros to the standard functions such as fxd_mem_copy() which macros to memcpy(). Nothing at all is offered for my own functions eg fxd_mem_format(). I use makefile solutions to build my programs with the source files attached to the project so they are easily editable in VS.NET. Can anybody provide suggestions as to what the problem is?
Thanks for any help you can provide
Steve.
Systems AXIS Ltd - Software for Business ...
|
|
|
|
|
Steve Thresher wrote:
I am having a problem getting intellisense to work with the header files for my libraries.
Many have. Head over to nntp://microsoft.public.dotnet.languages.vc. Maybe even better, check that NG from a Google Groups search.
++luck;
|
|
|
|
|
hi,
I have two classes.
CData
CHelper.
CData has an array (CArray) of CHelper.
CHelper has a pointer to CData so that nesting is possible.
Now,how to serialize CData so that even the nested things,any number and however deep it may be ,will also be serialized and importantly,retrieved.
Does inheriting CData from CObject help or should I bear the headache of the job?
PS:I am in the middle of a project and dont have much time to experiment all by myself.
Waiting..... 
|
|
|
|
|
During the output process, keep an array (using for instance std::vector) of pointers to the CDatas serialized so far. When it comes to output a CData, first check whether it's been already serialized (do a linear search on the vector), and if so write some check variable to 1 informing about this circumstance, followed by the index of the object in the vector. If the object hasn't been serialized yet, write 0 as the check variable and proceed with serialization.
On the input stage, do the opposite, constructing the vector on the fly as well.
This scheme has some weak points, like the linearity of the search for serialized objects, but this could be remedied if the need arises.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
yah,thought on similar lines but isnt tehre any built in methods to accomplish this?
|
|
|
|
|
There are serialization frameworks that do that automatically, but they are rather intrusive (esentially they require that you replace all your pointers with their own smart pointers that take care of the looping references), so I don't think it'd be a good idea to try to use them if you're in the middle of a project. The solution proposed is local (all the code is inside a function) and it is not that hard to implement.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Yes, if you use the serialization support provided in MFC, it will properly handle nested and even cross-linked objects. You need to use CObject as the base class, and add the appropriate DECLARE_SERIAL and IMPLEMENT_SERIAL macros. You also need a Serialize routine for each class.
Best regards,
John
|
|
|
|
|
I don't think MFC automatically supports serialization of linked objects. Basically it provides the barebones framework, all the work is left to the programmer. Please correct me if I'm wrong.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
MFC has complete support for serialization of linked items. I have used it for years with no problems. Internally it keeps track of which objects have already been serialized by using a map.
As long as you setup your macros correctly (DECLARE_SERIAL / IMPLEMENT_SERIAL), it handles all the details of loading and saving complicated data structures which are interlinked, even with loops of objects.
Best regards,
John
|
|
|
|
|
Oh... You were right, I've read some stuff on the subject and the mechanism actually does what you say (and in a pretty clever way.) I used to think ;FC serialization was dumber than it is.
Regards,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
jbarton,
You seem to have used MFC serialization for a while. Maybe you can help me out with this. I have a class derived from CArray, with not other variables in the class. I'm trying to serialize it to a TXT file. Here's my class definition:
class AFX_EXT_CLASS CFormList : public CArray<CString,CString&> <br />
{<br />
DECLARE_SERIAL(CFormList);<br />
public:<br />
CForm Item(CARSConnection &arsConnection, int iIndex);
void GetForms(CARSConnection &arsConnection, long lType);<br />
CFormList();<br />
virtual ~CFormList();<br />
};<br />
And then my implementation code:
IMPLEMENT_SERIAL(CFormList, CArray, 1);
When I compile it, it's giving me this error:
error C2955: 'CArray' : use of class template requires template argument list
Any idea what I'm doing wrong? 
Thanks much for any help
Mike Ellertson
|
|
|
|
|
Hi Mike,
You shouldn't derive from a CArray - it is not designed to be a base class (it does not have a virtual destructor).
Instead, you can make the CArray into a member of your CFormList class
<br />
class AFX_EXT_CLASS CFormList : public CObject<br />
{<br />
DECLARE_SERIAL(CFormList);<br />
<br />
public:<br />
void Serialize( CArchive& ar )<br />
{<br />
CObject::Serialize( ar );<br />
m_Array.Serialize( ar );<br />
}<br />
<br />
private:<br />
CArray<CString,CString&> m_Array;<br />
};<br />
<br />
IMPLEMENT_SERIAL( CFormList, CObject, 1 );<br />
Best regards,
John
|
|
|
|
|
Thanks for the input on this. I did just go ahead and derive from CStringList instead. Just for your info, I read an article on MSDN describing the right way to derive from CArray. So it is meant to be derived from.
I'm pretty sure the issue I was having was due to a bug in the way the Visuall C++ preprocessor interprets comma's in macro's. Another codeproject member let me know that and I found a bug report on Microsoft Website. But your solution worked, so I'm off and running.
Thanks!
Mike Ellertson
|
|
|
|
|
Hi Mike,
One thing that you should be aware of when serializing CArray (or other MFC collection classes):
Normally, when you need to serialize a CArray of some type, you have to check if the type is a POD. The default serialization support in CArray will do a binary copy of the contents of the CArray to the archive. This works for simple data types, but not for class objects. The correct way to fix this is to override the SerializeElements() function for the specific class that you are serializing. You didn't need to do this for a CArray containing CString objects, because Microsoft already provides an override for SerializeElements specifically for CString. If you change what is in the array to some more complicated object (rather than just a CString), you will need to override the SerializeElements() routine for this object.
Best regards,
John
|
|
|
|
|
John's answer is the way to go (I guess you already were using MFC serialization, so this is very good news to you.) The DDJ's article Inside MFC Serialization I've just read could be of some help for you (it was for me.)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
hi,
are-
* Subclassing
* Owner/Custom Draw
* Custom Controls
complementory,some what same,almost same or totally different?
i am confused
|
|
|
|
|
subclassing (when talking about controls) is where you take an existing windows control (like an edit box) and create a new version that does something differently than the original. it's not the same as C++ subclassing (creating derived classes), but the effect is similar. and with MFC it does work out to the same thing in most cases.
owner draw is where the control allows you to handle the rendering while it handles the back-end data work as usual. a common example is an owner-drawn button where you control the rendering of the button, but all the message handling is handled as usual.
a custom control is something you've built from the ground up.
-c
Garbage collection, making life better - for weenies!
|
|
|
|
|
It's probably good to mention one you omitted: superclassing.
A window is created by the OS as a thing with a callback procedure
and some data. The template for creation of this object is called the
windows class. (not related to c++ class. a window class is just
a spec sheet basically.)
Here's the jist:
SUBCLASSING: Have OS create a window from class X. Replace its callback
with your own. Take care of business in your callback and then pass
off to the replaced callback. (You won't be able to intercept creation
messages since that happens before you subclass.)
~ CREATE, REPLACE CALLBACK, HANDLE MSG, RELAY TO OLD
SUPERCLASSING: Register a new window class Y derived from X. This new
class extends an old class. Your callback gets called first even for
creation messages. You can still pass off to the old callback.
~ REGISTER CLASS, CREATE, HANDLE MSG, RELAY TO OLD
OWNER DRAW: Have OS create a window from class X. Set some data in the
window that lets its callback know that you want to handle some drawing.
The windows callback will route a message allowing you do drawing in
you message handling.
~ CREATE, HANDLE OWNER DRAW MSG
CUSTOM CONTROLS: Just an original window class and callback.
~ REGISTER CLASS, CREATE, HANDLE MSG
I'm probably missing some details.
|
|
|
|
|
I have been doing a bit of detective work on this problem, and have found 2 things that puzzle me ( a bit of an understatement).
First of all, the value of hwnd returned to EnumChildProc() always seems to be the value of lparam supplied to EnumChildWindows(). As if that wasn't bizarre enough, I have found that whilst in EnumChildProc() the value reported for 'this' in the variables window of the debugger changes on the four calls !!
As I have just discovered Spy++, I used the WindowFinder tool to establish the handles for all windows within my application. Would you believe that the four values (Caption and Client area for each of the two documents) corresponds to the 4 values of 'this'. (Yes, yes - I KNOW that one is a handle and the other is a constant pointer to the Document - that's what's so bewildering. More than a coincidence, don't you think ??) I believe this a BIG clue to someone who has more more experience than me.
H E L P !!!!!! (This problem is driving me NUTS !!!!)
My current code is as follows :-
(Incidently, I tried moving these 2 routines from the Document into the View, but it gives exactly the same sort of results)
void CIRCDoc::OnTapeMove()
{
// TODO: Add your command handler code here
CMDIFrameWnd *pFrame = (CMDIFrameWnd*)AfxGetApp()->m_pMainWnd;
// HWND hWndParent = pFrame->GetSafeHwnd();
// pFrame->SetWindowText("Hello Mum !!"); // DOES set mainframe title
// BOOL bResult = FALSE;
// LPARAM lParam = (LPARAM)(&bResult);
// BOOL rc = EnumChildWindows(hWndParent, EnumChildProc, lParam);
DWORD param = 0;
LPARAM lParam = 0; //(LPARAM)(¶m);
BOOL rc = EnumChildWindows(pFrame->m_hWndMDIClient, EnumChildProc, lParam);
}
BOOL CALLBACK CIRCDoc::EnumChildProc(HWND hwnd, LPARAM lparam)
{ TCHAR* pSaveText = new TCHAR[20+1];
BOOL rc = GetWindowText(hwnd,pSaveText,20);
DWORD wErrorResult = 0;
if(!rc)
wErrorResult = GetLastError();
delete pSaveText;
return TRUE; // keeps enumeration going
//SendMessage(hwnd,WM_SETTEXT,0,(LPARAM)"Test");
}
Doug
|
|
|
|
|
Apologies !! I accidently posted this as a new thread rather than an addition to my previous thread entitled "Problem with EnumChildWindows" of 25th June (I think ??)
Doug
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
