|
Mark:
A dll and a exe are similar, you can export function from a exe or from a dll, you can make all a application that is in a dll. The diference is that you need to know that you are calling a dll or a exe, because if you are calling a exe, this will be callin the winmain function or other function that you want to determine how entry point, but if you are calling a dll that have a application in, you need to know the ameof the function...
Sometimes I make that, I make a exe and this app, call dll like plugins....
best regards
Carlos Antollini.
Sonork ID 100.10529 cantollini
|
|
|
|
|
I know, but I was just wondering if it was possible to have both things in one file. Of course, it is possible to export functions from the exe file, but if it needs to be able to initialize itself before these functions are called a DllMain function would be nice in addition to WinMain. (of course, i could call an initialization routine from the exported functions, but that's not as fun  )
Actually what I'm trying to do is to make an .exe file which hosts shell extentions  This way I would only have to distribute one file, and not an external dll 
Enjoy!
Marc
|
|
|
|
|
When I use the menu command
Project>Add to Project>Components and Controls
VS opens the gallery window as it should, but it is empty. No ActiveX controls are listed. I checked the path, and it is opening into the 'Gallery' folder. So, in my attempts to figure out what the heck is up, I tried to add a (known) ActiveX control from my C:\WINNT\SYSTEM32 folder. Visual Studio complained that the control was not registered. So, I fired up the ActiveX Control Test Container to check out what controls are registered. The Test Container listed quite a few controls; all of the controls that should be listed in my Gallery window.
Anyway, as I see it, this all proves one thing...the ActiveX controls are all registered correctly on my computer, but for some reason Visual Studio doesn't know how to find them...any suggestions?
I'm running Windows2000, and I have the latest VS update, for all that's worth. Thank you very much for any help, I'd really like to have this functioning like usual.
~Cam Desautels
|
|
|
|
|
This is a good question. It's happened to me in the past as well and I've never known why. I hope someone has an answer.
Regards,
Alvaro
|
|
|
|
|
Hi Search for the following topic in MSDN,
It might be of some help.
"Reusing Code Topics"
|
|
|
|
|
Yes, i had actually checked out a number of these topics, but I did find something interesting:
The Gallery regenerates links to registered ActiveX controls every time you open it, based on the current state of the registry. This has certain implications:
If you delete a link to a registered ActiveX control, the link will still appear the next time you open the Gallery.
If you delete a registered ActiveX control (.OCX or .DLL file), but do not unregister it, the link will still appear the next time you open the Gallery. Of course the link will be inoperative.
If you copy an ActiveX control to your machine, but do not register the file, the link does not appear because the Gallery does not recognize the control.
...anyway, the important part is that the list is regenerated from the registry. I figured as much, but that doesn't explain the problem...grr...
|
|
|
|
|
I am creating a wizard using VC++ MFC, but I'm having trouble adding a bitmap header to the property sheet. My bitmap gets clipped by the property pages. What is the standard procedure to accomplish this?
Paul Jahans
|
|
|
|
|
If what you want is to allocate a little more space on top of the property sheet, add this snippet on your OnInitDialog():
CRect rectWnd;
GetWindowRect(rectWnd);
SetWindowPos(NULL, 0, 0,
rectWnd.Width(),
rectWnd.Height() + 100,
SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE);
CWnd *pWnd=GetWindow(GW_CHILD);
while(pWnd!=NULL){
CRect rect;
pWnd->GetWindowRect(rect);
rect.OffsetRect(0,100);
ScreenToClient(rect);
pWnd->MoveWindow(rect,FALSE);
pWnd=pWnd->GetNextWindow();
}
(Of course you'll want to change the offset to fit the dimensions of the bitmap header.)
Joaquín M López Muñoz
Telefónica, Investgación y Desarrollo
|
|
|
|
|
I have added a Menu Item to Popup default item File. After adding the Coommand Handler, when I run the app, the Menu item that I added appears Grayed. I am not sure why that is happening when the properties are not set to be disabled nor the code is written to do so. What would make the item Enabled or non-grayed by default.
|
|
|
|
|
Well, seems like MFC is not being able to locate the Command handler you wrote for that menu item. You could check if the handler is correct by creating a non popup menu (a fixed menu on the main windows, for instance) and inserting a menu item with the same ID. If the command handler is correct that item should be enabled (and the problem lies elsewhere).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
When I drag the Item to main bar, it is not grayed. Only when I nest it in the File option, it gets Grayed. I have the OnUpdateYourMenuItem too. Tried adding code to ENABLE the Item and still no luck.
|
|
|
|
|
Do you have a a OnUpdateYourMenuItem(CCmdUI *pCmdUI) handler for this menu item ? If you don't the menu item is disabled by default.
|
|
|
|
|
I did edit the ID few days back but, surprisingly, it doesn't behave that way when I have it at top level. Only when I make it a subitem, or within a popup, it gets grayed for no reason. I rebuild the files but no effect.
|
|
|
|
|
The reason that changes to resource.h do not always result in a recompilation is that VC++ insists on putting a line that says NO_DEPENDENCY at the top of it. I find this incredibly annoying. Why couldn't they make it a selectable option ?
|
|
|
|
|
You are exactly right and that is why it annoys me so much. I have figured out how to play their game though and remove the NO_DEPENDENCY line with a minimum of headache. I do this in nearly every project I work on. With the speed of computers these days I can think of no good reason to have anything NOT dependent on resource.h that uses it. It only causes problems and does provide no benefit.
|
|
|
|
|
Finally I found out the solution. I didn't associate the Menu to Main Frame. Instead I did to one of the views. Surprisingly it let me pick a view.
|
|
|
|
|
Hi.
One of the applications I've coded refuse to work correctly on WinXP (but was working fine for months under Windows 2000). I wonder if someone else notice this kind of problem.
More specificaly, I'm using anonymous pipes to make the two parts of my application communicate, but unfortunately the created process never get the handle of the pipes the main process creates. It results in the fact the the child process get the standard STDIN/OUT/ERR handles when it does GetStdHandle(). 
[Note: I'm not using CreateProcess, but CreateProcessWithLogonW. I can send a part of the code if it helps.]
|
|
|
|
|
Any body here Know where I can find some documentation about that?
Best Reagrds....
![Green Alien | [Alien]](https://codeproject.freetls.fastly.net/script/Forums/Images/alien.gif) Tomorrow is Friday!!!
Carlos Antollini.
Sonork ID 100.10529 cantollini
|
|
|
|
|
The foundational paper by Charles Simonyi.
It is my impression that Hungarian notation has fallen into some discredit during the last years, mainly because it promotes a very loose way of type checking. Languages more modern than C (like C++) have stricter type checking systems that render this kind of nmenomics redundant in the best case (or false in the worst, if you changed the type of a variable and forgot to rename it).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Gracias Joaquin,
Muy util, tu información....![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
Best Regards!!!!
Carlos Antollini.
Sonork ID 100.10529 cantollini
|
|
|
|
|
|
Thanks, it's very funny!!! 
Estaba interesado en esa notación porque un compañero de trabajo no la conoce.
I was interested in that notation because a co-worker don't know it...
Joaquín,
Thanks again
Muchas Gracias....
Carlos Antollini.
Sonork ID 100.10529 cantollini
|
|
|
|
|
I've created an ActiveX control with VC++ 6.0, and i try to call CoInitializeEx() at the beginning of a worker thread, but it doesnt recognize the API, and all I get is an undeclared identifier error for that
and COINIT_MULTITHREADED;
I linked to "ole32.lib" and i threw in in for kicks at the top of the .cpp and in a separate case, the .h
I AM LIKE ----------------| |-------------------
THIS CLOSE
to getting this crap... i dont have a clue... i've running the project on a different machine as well and i get the same errors. i've tried to throw in just about every other library as well... am i missing a library? Could someone show me what libraries they link to in a project that works? Any suggestions would be so helpful...
Thanks,
~Tim
SHABBA!!
|
|
|
|
|
Add this before the standard headers are included in your stdafx.h file
#define _WIN32_WINNT 0x0400
Chen Venkataraman
|
|
|
|
|
Let's all say it together kids:
"Chen Venkataraman is THE MAN"
thanks a whole whole whole whole whole bunch.
*BIG SIGH OF RELIEF*
~Tim
SHABBA!!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
