|
Assume that it's biggest program you're ever going to write. Multiply the struct size by 4. How much memory are you going to allocate?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
OK, you're right, it won't use up all my RAM. But is it really good programming practice to have all these unused variables lying around all the time?
-Sebastian
|
|
|
|
|
Good programming practice is to spend your development time on issues that really matter. I don't believe that loading ini settings at startup can hurt you or your performance. If it works for you, leave it, unless you have nothing else to do (in this case, it's better idea to go for some beer).
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
It's simply a matter of what is prudent within the context of the program's architecture. I think almost all of my programs do it that way (loading the ini data into a struct or object).
There is no "proper" way to do it really beyond obeying the laws of C++ physics. 
|
|
|
|
|
I though ini files where long since dead ...
I put everything in the registry these days....
Regards
Ray
"Je Suis Mort De Rire"
|
|
|
|
|
|
Oh sure, make me out to be the bad guy...
YOU BASTARD!
I KEEL YOU! I KEEL YOU ALL!!!!
|
|
|
|
|
I don't use the registry unless it makes sense to do so. The more data tha's contained in the registry, the longer it takes Windows to load. COM forces registry use, so if a program uses COM, there's no reason not to contribute to the registry bloat, but for simple programs, why bother?
INI files are alive and well - long live INI files.
|
|
|
|
|
I have a CToolBar member in my MDI app, it's a docking enabled toobar. If I float it, the user can click the little "x" button and close it. what actually happens to the toolbar in this case? how can I redisplay it later?
And is there a way I can handle the message generated from clicking that "x" button, without having to derive a class from CToolBar? or is that the only way?
Thanks
|
|
|
|
|
what actually happens to the toolbar in this case?
It's only hidden, window is not destroyed.
how can I redisplay it later?
Use CFrameWnd::ShowControlBar.
And is there a way I can handle the message generated from clicking that "x" button, without having to derive a class from CToolBar?
Not exactly. Actually, you'll have to subclass the CMiniFrameWnd window that hosts floating toolbar.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Hi,
I need to simulate the pressing of ALF+SHIFT keys through code...
Any idea to solve this problem?
Thanks!
|
|
|
|
|
Use keybd_event (on all 32-bit Windows versions) or SendInput (on Win98/ME/2000/XP/NT4SP3)
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I'm hoping someone will be able to answer this question with the extra info I have at hand.
I have put my code in a try catch block like this:
try
{
IFindFilesPtr pIFind(__uuidof(FindFiles));
pIFind.CreateInstance(CLSID_FindFiles);
if (pIFind == NULL) return;
}
catch(const _com_error & err)
{
CString strError(err.ErrorMessage());
AfxMessageBox(strError);
return;
}
And it crashes, telling me the class is not registered. The ATL based project that uses this class can find and use the class, the object is registered. Could anyone suggest what I need to do so that my MFC dialog based project can find my COM object ? I am initialising COM and uninitialising it in InitINstance and ExitInstance respectively.
Thanks.
Christian
Secrets of a happy marriage #27:
Never go to bed if you are mad at each other. It's more fun to stay up and fight.
|
|
|
|
|
Can you create an instance of the object using the straight COM APIs? (like CoCreateInstance) Try doing that, instead of using the stuff generated by #import.
--Mike--
http://home.inreach.com/mdunn/
"Make sure that if you are using a blow torch that you don't set anything on fire."
-- Chris Maunder
|
|
|
|
|
I took out the #import line, added includes for the _i.c and .h file and did this:
IFindFiles * pIFind = NULL;
HRESULT h = CoCreateInstance(CLSID_FindFiles,
NULL,
CLSCTX_ALL,
IID_IFindFiles,
reinterpret_cast<void**>(&pIFind));
if (FAILED(h))
{
return;
}
AfxMessageBox("Succeeded");
The message box does not come up, the pointer is still NULL.
Thanks for the help - I'm really excited about getting into this and I can't seem to get past this point.
Christian
Secrets of a happy marriage #27:
Never go to bed if you are mad at each other. It's more fun to stay up and fight.
|
|
|
|
|
What's the value of the HRESULT?
Also have you called CoInitialize before you try to create an instance of your COM object. I know that is one of my usual mistakes when creating COM objects in MFC.
Michael
|
|
|
|
|
It's funny you metnio that - I nearly fell off my bike riding home when I realised I'd not started COM. But adding Coinitialise and CoUnInitialise did not fix the problem. I actually create a new ATL object in my class and copied the copde across for the method and the new object creates/works perfectly.
I have no idea why the old one worked in an ATL client and not an MFC one, but I have it all working now, thank you.
Christian
Secrets of a happy marriage #27:
Never go to bed if you are mad at each other. It's more fun to stay up and fight.
|
|
|
|
|
I might be wrong - but
IFindFilesPtr pIFind(__uuidof(FindFiles));
is the same as this
IFindFilesPtr pIFind = NULL;
pIFind.CreateInstance(CLSID_FindFiles);
As the Constructor calls CreateInstance.
try using only
IFindFilesPtr pIFind(__uuidof(FindFiles));
The reason why you are getting "Class is not registered" could be down to many things make sure
1. The FindFiles dll (if it is a dll) is registered.
2. Make Sure the CoClass name is FindFiles and not anything else
|
|
|
|
|
Thanks for the reply, but I started with __uuidof et al, it crashed out the same as my current line does. Alling CreateInstance returns NULL instead of crashing.
1/ The dll is registered as code running in an ATL based app uses it successfully, and
2/ it does it using IFindFilesPtr pIFind(__uuidof(FindFiles));
If you have any other suggestions, I'd love to hear them.
Christian
Secrets of a happy marriage #27:
Never go to bed if you are mad at each other. It's more fun to stay up and fight.
|
|
|
|
|
Then the DLL should be properly registred.
I would suggest you debug DllMain in the COM Dll to see where
the loading fails.
(If it gets that far that is)
/Magnus
|
|
|
|
|
Are you instantiating this Object on a Separtate Thread ?
If you are then you will need to do a ::CoInitialize(NULL) at the begining of the Thread and a ::CoUninitialize() at the end of the Thread.
Each Thread needs to load the OLE Libraries.
|
|
|
|
|
hi all,
i wrote a vb application link to excel spreadsheet.
i would like to know how i can deploy this application. i found that the app. reference to excel9.olb. i have included it in my deploy setup file. however, the app. still failed to run. the runtime error is "ActiveX can't create server".
however, it work perfect after i installed office.
could anyone help me?
regards,
Jim
|
|
|
|
|
After installing Norton Antivirus ?
then unregister officeav.dll !!!!!!!!
|
|
|
|
|
hi all,
i wrote a vb application link to excel spreadsheet.
i would like to know how i can deploy this application. i found that the app. reference to excel9.olb. i have included it in my deploy setup file. however, the app. still failed to run. the runtime error is "ActiveX can't create server".
however, it work perfect after i installed office.
could anyone help me?
regards,
Jim
|
|
|
|
|
You're kidding right ?
First of all, this is the Visual C++ board, your question belongs on the Visual Basic board.
Secondly, you've obviously done this by using the COM objects exposed by Office, so how on earth is that going to work unless Office is installed ?
Christian
Secrets of a happy marriage #27:
Never go to bed if you are mad at each other. It's more fun to stay up and fight.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
