|
Is it possible for me to link an SDI in my dialog based application? For example, when a button in the dialog is clicked, an SDI comes up.
I've tried to 'File->Add->New Project' and added an SDI project into my current project but i have no idea how to link them up.
|
|
|
|
|
Probably you can go the otherway around :-
1.First Create an SDI application hide the mainframe .
2.Bring the Dialog to the Foreground.
3.On Button click hide the dialog and bring the framewindow to the front.
Regards,
FarPointer
Blog:FARPOINTER
|
|
|
|
|
while you click the button, you can
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CMyDoc),
RUNTIME_CLASS(CMyMainFrm), // main SDI frame window
RUNTIME_CLASS(CMyView));
AddDocTemplate(pDocTemplate);
m_pFormTemplate = pDocTemplate;
as usual in you button handler and show the MainFrame.
|
|
|
|
|
Sorry but I don't quite get what is 'AddDocTemplate' and 'm_pFormTemplate'.
|
|
|
|
|
well, if you create a project that is based on single document/view, you can see the code in CMyWinApp::InitInstance().
|
|
|
|
|
Hi to all
sorry if it's not the right place to ask this quastion!
I'm member of team wich works on rescue robots.our robot has laser scaner
and with the data it gives we can make maps.I want to know how can we make real time 3D model of an arena?or does any real time 3D model making example exist!
Best regards
Reza Razavi
|
|
|
|
|
|
They give informations about an anknown place.The data comes from the robot wich is in a mission and tells that where the wall's and other things are located!I should make a 3D model of that place and update it every time that robot sends new information and save it as a file that you can open it later and be able to surf on like a 3D game.So you think I can do it by learning opengl?I know a little about DirectX only worked with DirecInput.Can I do this with Direct3D??Wich one is the simple way ?is any example wich is close to what I want available?
Regards
Reza Razavi
|
|
|
|
|
Hello everyone,
I use VC 7 (Visual Studio.Net 2003) created a static lib, then I use VC6 to link with it in an application, there are some errors during link. Here is the source file of the lib,
<br />
int foo()<br />
{<br />
return 2008;<br />
}<br />
Here is the header of the lib file,
<br />
int foo();<br />
Here is the application using the static lib,
<br />
#include "foo.h"<br />
<br />
int main()<br />
{<br />
int a = foo();<br />
<br />
return 0;<br />
}<br />
When building the lib using VC7, there are no errors and the static lib is generated. When building the application and link it with the static lib, there are errors,
<br />
--------------------Configuration: VC6VC7lib - Win32 Debug--------------------<br />
Linking...<br />
VC7_static_lib.lib(foo.obj) : fatal error LNK1190: invalid fixup found, type 0x000C<br />
Error executing link.exe.<br />
<br />
VC6VC7lib.exe - 1 error(s), 0 warning(s)<br />
I can not find any useful information from MSDN. Could anyone help please -- how to use VC6 link a static library generated by VC7?
thanks in advance,
George
-- modified at 7:33 Tuesday 27th June, 2006
|
|
|
|
|
Maybe the older linker simply does not understand the new format of *.lib library files?
|
|
|
|
|
Thank you Viorel!
Your description is reasonable. Do you have any solutions? Maybe there are some methods to build static lib in VC7 for VC6 application?
regards,
George
|
|
|
|
|
I am afraid this is not possible. Library or object files for VC6 have to be made by VC6 or older linker.
Maybe you can convert your library to a DLL file. In this case I thing you will be able to access the DLL features using GetProcAddress function.
|
|
|
|
|
Thank you Viorel!
Why using static lib is not workable, but using DLL file is workable? What is the internal reason (linker compiler level reasons)?
regards,
George
|
|
|
|
|
In my opinion, the DLL files create by newer VS, in contrast with *.lib files, can be used in various operating systems and with different executables. When an executable requires a DLL function, it executes LoadLibrary and then GetProcAddress. Since these Windows functions can work with DLL created by both VC6 and VS 2003, in this way it seems to be possible to use a newer DLL by older executables.
|
|
|
|
|
Hello again Viorel 
Viorel. wrote: In my opinion, the DLL files create by newer VS, in contrast with *.lib files, can be used in various operating systems and with different executables.
Why DLL works but .lib does not work? There must be some internal (compiler/linker level) reasons, agree? What are the internal reasons?
Viorel. wrote: Since these Windows functions can work with DLL created by both VC6 and VS 2003, in this way it seems to be possible to use a newer DLL by older executables.
What do you mean "these Windows functions"? Do you mean LoadLibrary and GetProcAddress?
regards,
George
|
|
|
|
|
George_George wrote: There must be some internal (compiler/linker level) reasons, agree? What are the internal reasons?
Maybe the binary format of LIB files was changed for certain reasons, like new language features. I do not know if it is possible to force a lower linker level.
George_George wrote: LoadLibrary and GetProcAddress?
Yes.
|
|
|
|
|
Hi Viorel,
I am looking for solution at compiler/linker option level to solve the compatibility issue. Because in my application, using static library is better than using DLL. Any comments or ideas?
regards,
George
|
|
|
|
|
|
Thank you Viorel!
This forum is very cool.
regards,
George
|
|
|
|
|
|
Thank you Mike!
I have tried it just now and it works! Cool! I have a further question, about .DLL files, I think they should be both forward-compatible and backward-compatible, right? I mean if I create a DLL in VC7 and it could be used with VC6 and vice versa.
regards,
George
|
|
|
|
|
|
Thank you Mike!
I just can not belive why DLL can be used together even if they are not compiled/linked by the same compiler/linker, since I think there is no binary file standards between different compiler/linker, right? But I know that we can build a DLL and let even VB or Delphi utilize it.
What is the reason?
regards,
George
|
|
|
|
|
The problem isn't DLLs, it's C++ name decoration. The standard does not define a standard decoration scheme. So if 2 compilers, or 2 versions of a compiler, use a different scheme, their LIBs won't be compatible.
That's why many APIs are exposed from DLLs using extern "C" (no decoration at all) because that's the lowest common denomiator that all compilers can understand and use.
|
|
|
|
|
Hi Mike!
I do not think using extern C can bring us all the benefits (DLL can be used across different linkers, for example, VC and VB), but it can also bring us trouble, for example, we can not use function overloading in C++ when we use extern C since C does not have function overloading. Right?
regards,
George
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
