|
In what class is this code?
|
|
|
|
|
It is in the MainFrame class of my SDI appliction, and all I want to do is to insert a line into the CRichEditView
|
|
|
|
|
does anybody know why it doesnt work?
CString str;
str = "c:\\test.bmp";
SystemParametersInfo(SPI_SETDESKWALLPAPER,0,str,SPIF_UPDATEINIFILE);
but the following works:
SystemParametersInfo(SPI_SETDESKWALLPAPER,0,"c:\\test.bmp",SPIF_UPDATEINIFILE);
pleaze help!!!!
|
|
|
|
|
|
I get this error:
error C2664: 'SystemParametersInfoA' : cannot convert parameter 3 from 'class CString' to 'void *'
|
|
|
|
|
1) Next time you post a question make clear that you have compiler error
2) The error message is self-describing. 3rd parameter to SystemParametersInfo is void *. You can't directly pass CString object as void *. You need to cast like this:
SystemParametersInfo(
SPI_SETDESKWALLPAPER,
0,
(void *)(const char*)strWallpaperFile,
TRUE);
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
thank you!!!!! I'm just a newbie in C++, thanks again!!!
|
|
|
|
|
Hi,
almost every one of my programs uses an ini-file.
I have written a class that scans the file at program start and stores all variables in a global dynamically allocated struct.
Because this takes some memory when the program gets larger, I was wondering if scanning the file for a particular entry when it is actually needed wouldn't be the better alternative.
What is the 'proper' way to use ini-files and why?
-Sebastian
|
|
|
|
|
Hi,
I don't want to start a flame war here, but since I'm not using MFC and most of my programs don't have a big GUI, I find it too much a bother to write an options dialog, etc. everytime.
-Sebastian
|
|
|
|
|
While the discussion on reading ini at startup versus on-demand would be interesting, I think you should ask yourself if it's worth the trouble. How much memory are you using for this global struct?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Hi,
its not very much for a smaller program, but I was wondering if I should really store every minor option like background colors, switches for controls or windows the whole time the program is running.
Thanks for your time.
-Sebastian
|
|
|
|
|
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
|
|
|
|