I have a DLL written in Microsoft C 6.0 to be called by VB 6.0 main program. The VB 6.0 main program is compiled into an exe and copied to the DEBUG folder containing the DLL. When VC debug mode is started, a popup with exe not found is displayed even the VB exe exists in the folder.
Previously the VC Debug does function properly but all in a sudden the debug does not work. Please advise.
I'm breaking up a large application into some DLLs, and I'm having trouble with some dialogs. The DLLs are linked to the app implicitly, and use MFC in a shared DLL (in debug).
The problem is that dialogs internal to the DLL don't appear when I call DoModal(). By tracing the code, I've found that it can't load the dialog template, so the dialog fails to load. I've searched MSDN, but I haven't found anything that deals with dialog resources in an implicitly linked DLL.
What am I doing wrong? Do I have to do something to export the dialog template (and any other resources) when I compile, or do I need to do something in the linking application?
I am basically doing what you've suggested, with two important differences that I can see:
1) The function headers are not 'extern "C"' I just use the regular C++ definitions. I don't think that affects my project, since everything uses C++.
2) The function headers used by the app are not declared __declspec(dllimport). Would this prevent the dialog resources from showing? I doubt it, since the functions I call work just fine.
I can call all the functions I export no problem, without 'extern "C"' or __declspec(dllimport). Yes, the lib is imported into my project (so the dll is loaded implicitly). Basically, my code looks very similar to yours:
I've figured out what the problem is. Basically, the DLL needs to load the resources, and then properly set the resource source before you need to load one, such as when you want to load a dialog template.
This is not a question or cry for help.
Rather, I wondered if anyone would be interested in some code that performs adaptive histogram equalization (AHE in imaging circles). If I see enough demand for it, I'll dust off some old code, wrap it up into a nice demo app and submit it as an article.
For those not familiar with the imaging field:
AHE is an algorithm to enhance the contrast of an image.
Here is some background info:
I code C++ for unix at my job. I have my directory shared via samba to my windows desktop. I have VS setup to use as my IDE.
Here is one question:
We save our files as *.cc instead of *.cpp and VS doesn't recognize this as a C++ file therefor I get no syntax highlighting and all that other cool stuff. Is there a way to add an extension (*.cc) to the list of C++ files?
Here is another question:
I added another folder to my project called libs where I put all of our classes. We have a class called Cstring and if I type Cstring:: it will pop up the box with all of member functions associated with that class. But if I do something like Cstring str; then type str. it does not pop up that nifty little box. Anyone know how to fix this? (Note: I am not actually compiling the files on my windows machine. Just saving them and then compiling on my unix term.)
Thanks in advance,
There are 10 types of people in this world, those that understand binary and those who don't.
I have encountered your
Cstring::/ Cstring str / str. problem with the autocomplete
as well. Sometimes I find it works for non-C++ native classes and sometimes it doesn't. I suspect that it is a bit flakey.
Unfortunately I cannot help you, but would appreciate anyone else's input who can shed some light on this...
To force a file to be recognised as C++, use the /Tp option in your settings. Of course, you'll need to create a dummy project to have settings - put all your .cc files into it, and VC should be happy (it may even provide intellisense for you)
So. I build ansi - fine. I build UNICODE and I get this: Main.obj : error LNK2019: unresolved external symbol "void __cdecl SalieriFoundation::Globals::Func(class std::basic_string < unsigned short,struct std::char_traits < unsigned short > ,class std::allocator < unsigned short > > const &)" (?Func@Globals@SalieriFoundation@@YAXABV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z) referenced in function _main
Edit: as asked by first reply changed the linker error message - added some spaces to avoid HTML-like text. Also I actualy have namespaces that you can see in the error message so I added in the above sample code - but I don't think it makes any diff.
What's wrong? _UNICODE is defined in both projects.
I'm tying to find it for like 6 hours. Please help.
Are you sure it is linking with the unicode version of the static library? If both the unicode and ansi versions have the same filename (which is never a good idea), then it is possible that it is finding the ansi version first, and so never finding your unicode version of the function.
Have you seen Michael Dunn's article on Custom-Draw in List boxes? It's on this site (can't find link - it's entitled "Neat Things to do with CListCtrl using Custom Draw") - I have successfully followed that example to colour my List Box
Because, you haven't made the connection between the m_wndOk variable and the IDOKUNDCERVCREAT control, enabling m_wndOk won't do anything. The easiest way to achieve what you want is to lose the variables and just do:
I have an application which is using AviCap to occasionally grab a frame from a camera using a frame callback. I would like to convert this frame data into a bitmap or DIB (in memory). For testing purposes I have a static control (m_Pic) declared globally (for ease in testing) in which to display the bitmap to. I know the callback is working correctly because the static control turns black and resizes to the size of the captured imaged.
I've read through the samples here and at a few other places and I'm looking for a very simple method to get the image data without using any sort of custom class. Any help would be appreciated.
seems like I need some help trouble shooting again.
My app uses MS Speech API 5.1[^] and need to include the API for Win98 users. Problem is I am not sure which files to include? I have tried the Redistributable .msm[^]
Speech SDK merge modules (MSM)
The following merge modules can be redistributed:
The ones in bold are the ones I did not try installing.
Any ideas would be great thanks.
I think they installed properly but but app crashes when a speech function is called.
maybe I didn't create the installation correctly? www.savemall.net/mshelp.htm[^]
Later, JoeSox www.joeswammi.com It's not easy facin' up when your whole world is black Rolling Stones
I have part of an application that is SAPI enabled. It worked ok. I really didn't like that the end user would still need to get a speech engine. I could have sworn the ones that came with SAPI were only part of the SDK and not intended for end-user distribution. (??)
We finally ended up not enabling this part of the software over concern about support issues. It really did seem like a huge support quagmire. I would love to hear from people who actually ship this stuff and the resulting support costs.
I'm going to patent thought. I have yet to see any prior art.
Tim Smith wrote: We finally ended up not enabling this part of the software over concern about support issues.
Well I only am using it to speak generated text strings and display the Speech Control panel applet for the user to change voices and options. After that any problems, if any I will refer to MS or blame MS, in their documentation they suggest there are problems in some conditions.
Later, JoeSox www.joeswammi.com It's not easy facin' up when your whole world is black Rolling Stones
.... Well I though it was interesting. I'll start off with some background...
I am making this really cool app - it's really a super flexible imaging enviroment. One of its distinctive features is it's XML plugins. Each XML plugin contains a payload of C++ code plus a few other bits and pieces. So the app slots the pieces of C++ code from various XML plugins together and then runs them through a 3rd party compiler to make a "Processor" DLL, which the main app then loads and runs. This is useful because it allows the program to be fast and completly flexible even to the level of allowing users to edit the way image are created right down to the code!
Ok so really I have a couple of questions...
When you compile you get obj file which are subsequently passed through the linker. So what does the obj file contain? - I was under the impression that there was machine code in there. So if this is the case is it possible to load this machine code into memory manually, then use the beginning of the buffer as a function pointer, and then run the code that way?
This would be advantagous because I could cache machine code much more efficiently than keeeping loads of DLLs around. And instead of slotting together C++ I could cut and paste machine code together, so an XML plugin would only need recompiling every time the code was edited; and all the host would have to do is put the relevant machine code together then run it - all in memory - instead of clumsy compiling and temporaries and modules and stuff. Also cutting out the Linker would give obvious speed improvments, even I didn't do any machine code cut and pasting!!! On the other hand I was a bit worried because cutting out the linker might mess things up... Like the Implicit linking of the "Processor" DLL to the module... Can this worked around?
I realise this is a leviathon of topic, so I would be more than happy if somone could point me in the direction of a good source of information... Dynamic processing engines in general...
Anyway thanks for your time!!!
With time we live, with money we spend!
Joel Holdsworth wrote: So if this is the case is it possible to load this machine code into memory manually, then use the beginning of the buffer as a function pointer, and then run the code that way?
i don't think so, not easily, anyway. besides simply stitching the machine code in the .objs together, the linker also makes sure all the required functions are present, fixes up pointers from the .obj to external items (like external functions and variables) and a ton of other boring, but necessary things.
i'd go with an interpreted language with a nice C/C++ binding. write a bunch of primitive operations as built-ins, for speed, but do all the user's scripting in the interpreted language.
Yes I would tend to agree - the whole task is not easy. But there are a couple of good reasons why I'm not using an intirpreter - firstly is speed as you mentioned... I know that they do get faster than MsVB, but even so they are slow - I mean I'm talking about raytracing flyround movies of 3d fractals; I need power! Also writing an intirpreter sounds to me like a task as formitable as cut and pasting machine code.
Anyway thanks for the suggestions
With time we live, with money we spend!
This sounds like an interesting project indeed. To use the .obj files directly you would need to perform all the processing steps that the linker does. This is stuff like address fix ups, checking referenced code exists etc.etc. I don't think you want to go there.
A better approach is to use a language which runs in a virtual machine. Our programmer's editor (see sig) uses this approach. It has a C extension language, with some C++ features. Code is compiled once into vm code and then executed in an interpreter. Some virtual machines compile on the fly, without producing intermediate code.
There are several C/C++ VM's around including CINT, CH and UnderC, but the one I suggest you look at us UnderC at http://home.mweb.co.za/sd/sdonovan/underc.html[^] This is reasonably young project and is developing fairly slowly, but Steve Donovan is doing a good job. I had a play with an early version last year and was quite impressed. It has come a ways since then.
I'd be interested to hear how your project evolves.
Hmm yes that sounds like an interesting alternative... But what worries me is really the speed. You see with this project I expect to be pushing the boundries of image power - and I need just that raw power + flexiility. This is a much better VM than I had imagined, but i'd still expect it to be slowish. Bear in mind that I am talking about rendering fractals, and other such demanding imaging applications... Incidentally do you happen to know exactly how well it performs?
Alternativly I could save the user time if he/she was repeatedly recompiling by using the intirpreter, and doing an old style Compiler-Linker conventional compile when the code settles down!
(¸¸.·* ¸ .·*
(¸¸.~~> Joel Holdsworth.
If at all possible you need to have the CPU intensive stuff in straight C++ and just call high level routines from the interpreted code. So you wouldn't say draw 1M pixels, but draw me this object. I realize that may not be feasible here.
I have't done any performance testing, but my guess it would be fine for the sorts of things I'd want to use it for. Certainly the interpreted code in ED performs just fine. This is not UnderC though.
Starting with code in an interpreter is great for rapid prototyping, and then as you say, if performance is an issue, more it to native code.
I was wondering what the difference between ON_MESSAGE and ON_THREAD_MESSAGE is? It seems in the documentation it states that when you have a CWinThread class that you should use ON_THREAD_MESSAGE. Does this mean you should use ON_THREAD_MESSAGE everywhere, or just where the thread is posting messages?
You use ON_THREAD_MESSAGE in your CWinThread derived class to handle messages sent via PostThreadMessage(). You use ON_MESSAGE to handle messages sent via SendMessage() or PostMessage() (or others) in CWnd-derived classes, even if the message in question has been sent between threads.
The LPCTSTR operator on the CString returns a constant string - you should never cast it to non-const string to change it. So while the first example will compile, and possibly work (depending on what Arxiu.Write() does), it is bad practice, and could cause problems.
You only need to call ReleaseBuffer() after a call to GetBuffer() to tell the CString to take control over the buffer again (and allowing you to call other methods).
First, if Arxiu.Write is not going to modify the string, then it should be declared as a LPCTSTR and not LPTSTR. Then the problem just magically goes away.
However, if you have no control over how Arxiu.Write is defined AND you are 100% sure that it does not modify the buffer, then (LPTSTR)(LPCTSTR) is safe but bad style and risky. The only time I ever use that construct is when I am working with Windows API where some structures are dual purpose and thus can not be defined as const when they are being used in a read-only context. (i.e. SetItem for tree views)
Now, you will need to invoke ReleaseBuffer in method B.
For some reason I can't find/use the ATL Object Wizard in MSVC6. The button to use it is disabled and its not under my Insert menu. I have the folder and all the files for the Object Wizard (C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Template\ATL) but I cannot use it. Should I reinstall or is there a way to turn it on?
Thanks for any help.