|
Is it possible to generate a lib file from a DLL? I downloaded a DLL and it only comes with a def file. I would like to use the DLL the easy by including the lib for the DLL at compile time?
I could recompile the DLL source, but would prefer to use some tool to generate a lib file from the existing DLL
Thanks! 
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
If you've got a DSP for it then add this to your project and make it a dependancy of the project. That's the easiest way. VC++ will do the rest.
I think there is a utility to create a lib, but I can't think what it is just now.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Neville Franks wrote:
If you've got a DSP
Nope 
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
Hockey wrote:
Neville Franks wrote:
If you've got a DSP
Nope
Should be easy enough to just create a nice new one and whack all the files into it.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
IMPLIB used to do it for Win16.
maybe this can help:
http://www.geocities.com/SiliconValley/5806/download.htm#IMPLIB
-c
I'm not the droid you're looking for.
|
|
|
|
|
Cool...i'll check it out
Thanks!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I know for sure the VC4.2 linker could do it. I don't know if they removed the option from later linkers (quite possible, since it was something useful).
Anyway, it went something like
link /def:foo.def foo.dll
and voila, an import .lib was generated.
|
|
|
|
|
hi all,
I have MDI app. whish has 1 document 3 view objects. I'll display three different graphical scenes in each window. So I modified view classes (CView1, CView2, CView3) in order to use opengl... I setup pixel formet get rendering context, make current etc...
if I modify only one view class app. works (only one view displays graphical scene), BUT if I modify 2 or all view classes for opengl, app. locks when I make full screen. If I comment wglMakeCurrent line app. doesnt lock. What's the problem with wglMakeCurrent..
if((::wglMakeCurrent(m_pDC->GetSafeHdc(), m_hRC))==false)
{
MessageBox("Cant make rend. context current");
return false;
}
If wglMakeCurrent runs in one view everthing is OK, But if all views run wglmakecurrent it crashes when I make fullscreen? I guess that all of the rendering contexts cant be made current at the same time, but why doesnt it crash when working in non-fullscreen mode..
I want to know what wglMakeCurrent exactly does? And why it crashes when I make fullscreen?
a second question:
Is there a tool that I can draw geometrical objects (2d or 3d) and tool creates opengl code for the objects?
sorry It was a long post but my english is this enough
|
|
|
|
|
You should probably refer to the excellent article CGLEnabledView - An MDI view class supporting OpenGL
[^],you will find useful info into.
wglMakeCurrent associates/de-associates the OpenGL rendering context to the Win32 device context.
Sometimes with OpenGL the problem comes not from the code, but from the implementation of OpenGL in the video card, that's why I would advise to test the application on different computers using different video cards.
I've no idea about your second question, but if you find such a tool, I would be happy to know it, TIA !
HTH,
K.
One small village of indomitable geeks still holds out against the invaders. And life is not easy for the managers legionaries who garrison the fortified camps of Microsoftum, Javum, Ceplumplum and Vebasum
|
|
|
|
|
thanks for the link..
and I found a program named Deep Exploration that can convert 3d studio or other files to opengl source
www.righthemisphere.com
|
|
|
|
|
hey everyone... whats the difference between managed c++ and regular c++??
|
|
|
|
|
Regular c++ is not managed . The difference is that managed is executed under .Net runtime (or whatever they call it) therefore there are certain limitation/differences. Totally different memory allocation, memory access(mostly none), data types etc.
|
|
|
|
|
Is there an article or website that describes the details and differences of both?
|
|
|
|
|
Managed C++ is .NET dialect of C++. As you probably know, in .NET it is Common Language Runtime that manages lifetime of objects, while in "raw" C++ it is entirely up to you how to manage memory. If you compile a C++ application with /CLR compile switch, you can make CLR calls from inside your C++ program.
Вагиф Абилов
MCP (Visual C++)
Oslo, Norway
Hex is for sissies. Real men use binary. And the most hardcore types use only zeros - uppercase zeros and lowercase zeros.
Tomasz Sowinski
|
|
|
|
|
|
managed c++ is a marketing con, C++ is the most widely used language on the planet for commercial applications.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not
as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
thanks
|
|
|
|
|
The CxImage *i is just an image that I want to get drawn onto this CDC.
It works fine if I Draw() straight to the window DC, but if i use this class and try to BitBlt() from this to the window DC, I get nothing.
What could be causing this?
class CSomeDC :<br />
public CDC<br />
{<br />
CBitmap bmp;<br />
CBitmap *bmpOld;<br />
public:<br />
<br />
Uint32 w, h;<br />
<br />
void Init(CxImage *i)<br />
{<br />
w = i->GetWidth();<br />
h = i->GetHeight();<br />
<br />
VERIFY(CreateCompatibleDC(0));<br />
VERIFY(bmp.CreateCompatibleBitmap(this, w, h));<br />
bmpOld = (CBitmap*)SelectObject(bmp);<br />
i->Draw(m_hDC);
}<br />
};
|
|
|
|
|
Locked Ghost wrote:
VERIFY(CreateCompatibleDC(0));
For a start why is 0 being passed here. It should be 'this' me thinks.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
0 = Current display DC or something like that(Memory bad. From MSDN)
this? well, why would I want to create a DC compatible with itself, which has not been created yet? :p
|
|
|
|
|
hey Brian do u know Chris-de-Burgh ? 
-=Ehsan-de-Burgh=- 
|
|
|
|
|
Brian? Chris-de-Burgh? Never heard of either one
|
|
|
|
|
Locked Ghost wrote:
0 = Current display DC or something like that(Memory bad. From MSDN)
I think its for the Desktop. Is that what you want?
Locked Ghost wrote:
this? well, why would I want to create a DC compatible with itself, which has not been created yet? :p
Because that's what you do with memory dc's. Have a look around CP for CMemDC by Keith Rule.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Neville Franks wrote:
Because that's what you do with memory dc's. Have a look around CP for CMemDC by Keith Rule.
Tried, still doesn't work
And CMemDC does not do that actually.
|
|
|
|
|
I've run into this myself in the past. You are creating a DC which initially has a mono 1x1 bitmap
selected into it (look at ::CreateCompatible DC...) You need to create a HBITMAP compatible with the
end DC (e.g. Screen).
You need something like:
void Init (CxImage *i)
{
CWindowDC dcScreen (CWnd::FromHandle (::GetDesktopWindow ()));
w = i->GetWidth();
h = i->GetHeight();
VERIFY(CreateCompatibleDC(&dcScreen));
VERIFY(bmp.CreateCompatibleBitmap(&dcScreen, w, h));
bmpOld = (CBitmap*)SelectObject(bmp);
i->Draw(m_hDC);
}
I hope this helps,
Iain.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
