|
One other way that library references get into your code is through the #pragma comment(lib, ...). Admittedly your find-in-files should have picked this up - unless the pragma's hidden in a library header outside of your project.
To help track it, turn on 'verbose' mode on the linker tab - it spews out a huge amount of essentially useless information, but buried in there may be a handy clue as to why the linker thinks it needs your 'retro' DLL! Happy hunting!
Matt Godbolt
Engineer, ProFactor Software
StyleManager project
|
|
|
|
|
Thanks, that's really helpful, I had no idea that was there. It's told me that the mfc42d reference is in a thrid party lib in another directory all together (..\..\ ...). On the next challenge then....
-Dy
|
|
|
|
|
Hi All,
I am searching for a way to fading black the entire screen to do some effects.
Is this possible to programmatically control contrast and luminosity with the graphic card (maybe DirectX?) or to fade to black the desktop window?
Thanks.
|
|
|
|
|
One way to do this is to overlay the desktop with a new window (that paints itself black). Then, change the transparency of that window from completely transparent to completely opaque.
/ravi
My new year's resolution: 2048 x 1536
Home | Music | Articles | Freeware | Trips
ravib(at)ravib(dot)com
|
|
|
|
|
In fact, I had this solution in mind, but I wanted to know if another way could exist.
Thanks for your reply.
|
|
|
|
|
Hi,
I'm wondering whether Visual Studio .Net 2002/2003 has a similar feature, which I used sometimes in Borland CBuilder quite extensively. When debugging an application, all valid breakpoints were marked in the debugger view of the source editor. This way, one could easily find unused / never called functions. Visual Studio only sets a breakpoint to the next valid position, if one accidentially tries to set a breakpoint to an unused codesection.
Is there an easy solution to setting up the editor to show all compiled codelines ? Or are there any AddIns, which manage that? This would be a great help for code cleanup, when trying to remove unused #idef switches, functions, etc.
Thanks,
Florian
|
|
|
|
|
VS.NET does not need to detect unused routines because in release mode they are not included in the executable (removed by the linker).
Don't try it, just do it! 
|
|
|
|
|
Hi,
Alexander M. wrote:
VS.NET does not need to detect unused routines because in release mode they are not included in the executable (removed by the linker).
well, that's not my main problem. I want to use the information what is NOT compiled to do some refactoring and cleanup of the source code. Therefore it would be extremely useful to see all codelines marked, which are really existing in the binaries. Of course, this is just one small step into refactoring old code.
Any tools or settings known to achieve this ? This was really nice in CBuilder.
Bye,
Florian
|
|
|
|
|
Hi, I need to know the status of a process? I launch a simulation programm that runs about 1 minute. During that time, I must find a way to question the process to know if it's actif or not. I know that I can use WaitForSingleObject(process, INFINITE); to wait until it's finish, but for some personnal reason, I can't use it for my project.
How can I find the status of a process? I would like to have a function like GetStatus(process, ID) of somme sort. True if it'a still actif and false if finish!
HANDLE process;
process=launchViaShellExecute(path,CommandDOS);
//GetStatus(process) (Actif or not)
Thanks
JS
|
|
|
|
|
GetExitCodeProcess
However, I hope you can overcome your 'personnal' reason, because without using WaitForSingleObject you are now actively avoiding the proper and recommended manner to detect that the process has exited.
|
|
|
|
|
I agree totally with Blake's sentiments here; but another (possibly as ugly) alternative is to call WaitForSingleObject(handle, 0); - this checks the state of the object wihtout blocking.
A return code of WAIT_TIMEOUT would mean the process is still running, otherwise the process has exited.
Matt Godbolt
Engineer, ProFactor Software
StyleManager v1.00 now released!
|
|
|
|
|
I create combo box dynamically
<br />
CComboBox *combo;<br />
combo = new CComboBox;<br />
CRect rt(10,0,100,10);<br />
combo->Create(WS_CHILD|WS_VISIBLE|WS_VSCROLL|CBS_DROPDOWN, rt, this, IDC_COMBO3);<br />
but when I click on the drop down arrow, the drop list don't appear. Only a thin narrow black line is shown below. How can i extend the drop down list?
thanks.
|
|
|
|
|
If you are using Visual studios go into the Resource view, and find you dialog box. open the box then put the cursor over the down arrow that would normally open the list. This will cause a outline of your drop-down list box to show up make the outline larger, for some reason the default setting "even though it looks big enough to show information" is so small it will not display anything.
|
|
|
|
|
I can't customise it through controls and resource view, the combo box is created dynamically , not in resources.
|
|
|
|
|
george ivanov wrote:
CComboBox *combo;
combo = new CComboBox;
CRect rt(10,0,100,10);
Make the height more I believe.
CRect rt(10,0,100,300);
this is this.
|
|
|
|
|
|
I have a VS.net C++ Project that requires certain DLL's exist on the users system to run. As part of the project I would like to detect the users OS and install the dll's in the required system folder(s) when the user starts up the application. Can I do this or should I just create an installation disk to handle it?
Thanks.
Jerry
|
|
|
|
|
If you have statically linked your program to the dlls, then you will need an installation program I believe.
If you are loading the dll files dynamically using LoadLibrary(...), then you can have the dll files in the exe as resources, and copy/install them onto the system if they are needed.
this is this.
|
|
|
|
|
khan++ wrote:
If you have statically linked your program to the dlls, then you will need an installation program I believe.
No, you cannot link statically to dynamic link libraries. SLL's are compiled libraries that will be linked together with your program. It will make your executable larger...
DLL's however are linked to at runtime. When you run your program, DLL's can be loaded at startup, on demand or manual. This requires extra files (DLLs) to be shipped with your product.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote:
DLL's however are linked to at runtime. ...
Exactly. I used the wrong words. Thanks for the correction.
this is this.
|
|
|
|
|
He probably should have said 'implicitly' linked to the DLL.
Static Linkage - Traditional LIB files - MAkes EXE larger.
Implicit Linkage - DLL Files - Exe not necessarily larger, but won't run if DLL cna not be found and loaded.
Dynamic Linkage - DLL Files - Your EXE does LoadLibrary and GetProcAddress to load the DLL and call functions. With this method, your own EXE could possibly deploy DLL.
|
|
|
|
|
Hello,
Why would you wan't to place the DLL's in the system folder? Most people hate it when 3rd party libraries are placed in those folders..
Anyway, I think that it is better to make an installation disk and do some checks when the DLL's are needed. Don't install the DLL's when you detect an error, but inform the user and let him take appropriate actions. Make sure that you have the DLL's ready on your installation disk, so the user can copy them when he / she needs them.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Also, the OS hates it. The OS might hate it so much, that the user running the program will not even have access rights to copy files to the system folder! That is a lot of hate 
You could put the folders into a location ALL users have access to and then investigate "App Paths" registry entries for your EXE(s) to set up that folder as a location where DLL will be searched for loading.
|
|
|
|
|
I think that developers should keep the DLL's in the application folder. I really hate to see one application have different folders in multiple system folders.
IMHO one should set a registry key for a DLL that is installed and applications should check that DLL before installing, etc., etc.. This way, the files are manageble by the user. Also this technique allows different versions of DLL's with the same name to exist on the same system, thus avoiding DLL hell!
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I need to multicast a bitmap image over the network with UDP and can't get it to work. Can someone please help me with full VC++ code to do this?
BoB
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
