|
How can you do that? can you please supply a link because i tried looking for it and did not succeed.
LINK uses the following types of input files:
* .obj files
* .lib files
* .exp files
* .def files
* .pdb files
* .res files
* .exe files
* .txt files
* .ilk files
Thanx
llp00na
|
|
|
|
|
You can't create a static link library from a DLL. Do you mean create an import library from a
DLL? If so, if you have the source code to build the DLL, then you can set up your project to
create the lib when the dll is built. If you need an import library for a DLL that you DON'T
have the source for, try How To Create 32-bit Import Libraries Without .OBJs or Source[^]
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I created a new project using the MSVS2005 wizard.
Modified my CView class to be able to print text, and it works all cool.
If I put in the CView class code to add lines to my array of strings, it will print it like I want on the screen.
I want to be able to access functions I wrote for my CView class, from my CWinApp class.
But when I try, it given an "... Access Violation reading location:...".
I understand that this happens because the CView class makes its own thread, and works in it, while the CWinApp is in another.
But I can't figure out what to change/add/remove to make it work...
Any ideas?
|
|
|
|
|
I understand that this happens because the CView class makes its own thread, and works in it, while the CWinApp is in another.
No. CView does not make its own thread. There is a single thread in a standard MFC application unless you specify your own threads. CWinApp makes the primary thread, so called UI thread and, particularly, CView object is created there.
Try the following code to access the view. Do not call this code before InitInstance method because InitInstace should have created the view (frame and doc as well) before any attept to use it [view].
CMyView *pView = (CMyView * ) ((CFrameWnd *)AfxGetMainWnd())->GetActiveView();
--
=====
Arman
|
|
|
|
|
I am using a small bitmap (10x15) on a dialog resource that shows up as a different color than black (a lighter shade of black, actually) on a different monitor. Both monitors have the same screen settings and both are running Windows 2000. Other resources on that dialog display as black on one monitor and the same on the other monitor. Anyone have any ideas how to possibly correct this anomaly?
Thanks.
John P.
|
|
|
|
|
Palette?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
If I look at the bitmap in a 'paint' program, the color looks fine (on the PC where the color on the dialog looks different). I don't believe the pallettes are different, but it's worth looking into I guess.
thanks.
John P.
|
|
|
|
|
As cpallini mentioned - a palette can be necessary depending on the pixel format/bit-depth of
the bitmap and how you are drawing it.
So, how is the bitmap being drawn and what format is it? 
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
The bitmap is being used by other owner-drawn dialogs and the color is fine. The bitmap is 10x10 pixels and is suppose to represent a 'phillips screw'. I use this bitmap in a non-owner drawn dialog as a static resource placed in specific locations on the dialog. I can not find a specific palette withing the project. All colors have been defined withing include files. When viewed on my PC at my desk, there is no change in color on this bitmap when I use them as static controls on the dialog. On the PC where the application is actually used, this bitmap is displayed in a color that is not as deep a black color as found on the desk PC. And as previously mentioned, the screen attributes are the same on both PCs and both run Windows 2000. So, the confusion remains as to why the bitmap shows up as two different shades of black. Any ideas why?
Thanks.
John P.
|
|
|
|
|
jparken wrote: The bitmap is being used by other owner-drawn dialogs and the color is fine.
Then I still ask - What code are you using to draw the bitmap? What format is the bitmap
(bits-per-pixel and planes)?
There must be something about the way you are handling the bitmap that differs from the working
code
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
The bitmap is included as a 'picture property' part of the dialog. I'm not 'drawing' the bitmap. All I do is place it in a location on the dialog resource.
John P.
|
|
|
|
|
Sorry for the confusion What is the "'picture property' part of the dialog"?
You're NOT using a picture (static) control?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
The picture property is a static control (defined with an IDC_xxxxx). If you select 'Picture' from the toolbar, it will default to IDC_STATIC. But the color on the picture (bitmap) is different when running the application on separate PCs.
Hope this explains the problem more clearly.
Thanks for your time.
John P.
|
|
|
|
|
hmm I can't imagine why it would draw differently on different PCs.
Can you post the exact control resource code for the static control from the .RC file and any code
you use to manipulate the control?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
From the .RC file:
CONTROL 197,IDC_STATIC,"Static",SS_BITMAP,12,15,10,10
CONTROL 197,IDC_SCREW2,"Static",SS_BITMAP,195,15,10,10
CONTROL 197,IDC_SCREW3,"Static",SS_BITMAP,195,55,10,10
CONTROL 197,IDC_SCREW4,"Static",SS_BITMAP,12,55,10,10
And I don't manipulate the the static control once I have it placed on the dialog (which happens to be a numeric keypad). The bitmap is nothing more than a representation of a small phillips screw head. As I said in prior postings, this same bitmap is used throughout the total project of numerous dialogs, and all of them make use of this bitmap at the corners of the dialogs.
John P.
|
|
|
|
|
jparken wrote: I don't manipulate the the static control once I have it placed on the dialog
Don't you set a bitmap to the control?
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Maybe I don't understand the question, but I select and place the bitmap on the dialog in the location I desire. Is that not setting the bitmap to the control? I set the control name in the Properties box, instead of accepting the standard IDC_STATIC for all four of them.
John P.
|
|
|
|
|
ACK never mind - You showed the bitmap ID in the resource 
Well, I can't imagine why it would draw different!
The bitmap is 10x15 and you can tell the shade of black is different? Good eye!
What if you make a new bitmap, filled with black, and substitute it in the resource. Does that
show as black or gray?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
I haven't tried that. It will take a while to do though. This app is running on a flight simulator, so I can only try this when the simulator is not in use, so it may be next week before I can get back to you.
Thanks for all your assistance!
John P.
|
|
|
|
|
Hi to all of you,
I am a new programmer on OpenGL.
I am currently working on an application where I have a Debian Linux PC with two usb industrial cameras,acquiring images at a rate of 25fps. Each image data is sent by sockets to a windows PC. The format of the received buffer at the windows PC side is buffer[0]='top left image pixel', buffer[640*480]='bottom right image pixel'. I want know to proccess these buffers an display a video on an OpenGL window at a similar frame rate, or even lower,i.e. even 5-10 frames per second will do for me.
I am using Dev-C++ on the windows PC.
Can anynone advised me with an appropriate approach?
Cheers,
DoctorDoctor
|
|
|
|
|
...from system32 even if it is copied to the directory the application starts from? I just dealt with a customer over a bug due to this very issue. Two DLLs with the same name were on the system. One DLL was loaded by one application and then the other application loaded the first application's DLL instead of its own. Result? Confusing "ordinal/export not found" messages and the second application refused to start.
The Windows loader should be smarter than that. I'd love to hear the rationale behind why Windows can't run a quick check for the DLL in the application's directory BEFORE looking for a cached DLL of the same name elsewhere. Caching systems, by definition, must reflect the equivalent non-cached system 1-to-1.
Non-cached DLL search order[^]
|
|
|
|
|
I suppose that's why MS tacks version numbers on to runtime DLL names
Sorry for your lost time debugging!
Unique DLL names are a good idea 
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
dontknowitall wrote: I'd love to hear the rationale behind why Windows can't run a quick check for the DLL in the application's directory BEFORE looking for a cached DLL of the same name elsewhere.
Wouldn't that sort of defeat the purpose of cached DLLs? After all, RAM is much faster than the HDD.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: Wouldn't that sort of defeat the purpose of cached DLLs? After all, RAM is much faster than the HDD.
No - it wouldn't defeat the purpose. The point of caching DLLs is to reduce the amount of RAM used. If two applications happen to have a DLL of the same name and one is running and the other is started, the second application will attempt to use the first application's DLL. Checking for a file's existence in the application's directory before looking at the loaded DLL cache takes almost no time (and could potentially be done in RAM altogether because the file system caches information like that in RAM).
A cache, by definition, should return the same exact result as the method used to generate the cached information. To deviate from the definition will cause bugs to appear. Windows does not do this and therefore has "bugs". LoadLibrary() documents this weird behavior but that doesn't make the behavior right/correct.
|
|
|
|
|
It's been this way since the beginning. IMO a part of the whole DLL hell thing.
It's one of those backward compatible things that couldn't be changed and we have to live with it.
The caching works fine. It is IMO appropriate to look for an already-loaded DLL before going to
disk to get it.
The problem is, it's done by NAME ONLY. I think it should look at name and VERSION at least.
But it doesn't. Complain to Microsoft...good luck 
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
