|
How to retrive the tables from Database (.mdb) file
Plz .Urgent
Rondla
|
|
|
|
|
I was Including Shlwapi.h file in my ctAppRuleParser.cpp.. but i stuck up with the following error
i am using #define _WIN32_WINNT 0x0500 in my application.
ctAppRuleParser.cpp
F:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\Shlwapi.h(56) : error C2146: syntax error : missing ';' before identifier 'DECLSPEC_IMPORT'
F:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\Shlwapi.h(56) : error C2501: 'EXTERN_C' : missing storage-class or type specifiers
F:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\Shlwapi.h(56) : fatal error C1004: unexpected end of file found
ctcapsule.cpp
How can i solve this compilation problem.
Sunil Virmani
|
|
|
|
|
Are you defining _WIN32_WINNT before you are including shlwapi.h? Do both of these exist in your project's stdafx.h file? If so, what does the rest of that file look like?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Hi again
When I copy my new application that I have been slaving over to my target PC, I come up with the above error when it is run. Of course, I can go through and copy all the required DLLs over manually as the application tells me they are missing, but there must be a better way!
Is there a method of finding out what resourses have been used by an application? I am using VC++6.0, Windows XP (and 98 sometimes)
Thanks for any help
Mike
|
|
|
|
|
You can use the depency walker tool that is provided with Visual Studio. It will show you all the dll that your application uses.
|
|
|
|
|
Thanks for this. I have just fired up dependency walker and it looks like it does exactly what I want!
Thanks again
Mike
|
|
|
|
|
Mike Winter wrote:
but there must be a better way
Well Mike, firstly - if you are using MFC, then you will have to provide those dlls(mfc*.dll) whereever you ship your application. Secondly - there are better ways, but not THAT better as you are expecting. As of now, I only know two ways:
1. Make an installer, using Installshield or similar software, and include ur dlls with the installer.This is better option as once these dlls are installed, there is no need ship those dlls again on that machine.
2. Statically link the MFC dlls in your application. This will make ur application very heavy. I guess size increase is about 2 Mb and thats the reason enough why this is a bad idea.
so choose ur way...
"Do first things first, and second things not at all."
— Peter Drucker.
|
|
|
|
|
You don't happen to be trying to run the debug version, are you? I had that problem too, saying such and such dll was not found, when I realized I was compiling in debug. If you compile in release (if this is your problem) that problem should go away.
Hope this helps!
Danny
The stupidity of others amazes me!
|
|
|
|
|
I'd like to create a program that has a VB interface but the functionalities came from VC, I think it means using dll files to link the two. The VC will create the server dll and the VB will call them. I came across ATL and COM and found them useful but I'm still a beginner with regards to them so I'd like to ask where do I have to focus to? ATL or COM? I'm a bit on a hurry for a school machine problem and I can't afford to study both of them thoroughly.
I'd like to know their pros and cons and limitations?
Which of them can support MFC functions, can open a file, supports CString, etc, in short, with less limitations?
Please help, any articles will do. Especially regarding an overview of ATL vs COM will do for me to be able to decide which of these 2 should I use. Thanx 
|
|
|
|
|
Hi !
If you need only to call some function that will do some specific tasks (like you said, opening a file, CString, ...) then I suggest you to make a regular dll (so, no COM and no ATL). I don't know ATL so maybe I'm wrong for this part but COM is more oriented to deploy controls and components (and so, if you want just some 'simple' functions, that will be more difficult to implement). I think ATL is more or less the same (with other librairies).
You can create a MFC dll so that you don't have to deal with the 'internals' of the dll. You can just then export the functions you need.
I think there are some articles on this website about dll creation. Anyway, if you have some specific questions, don't hesitate to ask again.
|
|
|
|
|
cedric moonen wrote:
You can create a MFC dll so that you don't have to deal with the 'internals' of the dll. You can just then export the functions you need.
Will MFC dll be able to do what a console app can do? Because, since it will be on the background it will work just like a console process but the display or GUI will thrown out to the calling VB function. What are the limitations of MFC dll over com/atl that made you say that when I'm just going to create simple MFC functions, I'd better use this one?
Thanx for your time
|
|
|
|
|
The MFC dll won't show any window or else... The MFC will just help you to get rid of the development of some specific functions you need to implement in your dll (it will be done for you).
benjnp wrote:
Will MFC dll be able to do what a console app can do?
This doesn't mean a lot. You want your dll to display a console ? If not, then your sentence doesn't mean anything because the dll won't display you the console.
Ok, let's take an exemple. You will be able to do things like that:
int Sum(int a, int b)<br />
{<br />
return (a +b);<br />
}
I thinkm this is what you want to say by 'console application'. So, yes, you can simply export functions that will be called in your VB app.
benjnp wrote:
What are the limitations of MFC dll over com/atl that made you say that when I'm just going to create simple MFC functions, I'd better use this one?
It's not really a matter of limitation but rather trying to use the best tool suited to your needs. The problem with COM is that it has been designed to share components or controls. So there, you will have the problem that it will be used in VB like a control (and then here, you will have to do some things not really clean to avoid this behavior). If we take my previous example (the sum of two numbers), you will need to 'embedd' this function in a component and then access this component through an interface,... So you see, it is deploying a bazooka to kill a bee 
I hope this is clear enough.
|
|
|
|
|
cedric moonen wrote:
Ok, let's take an exemple. You will be able to do things like that:
// In your dll:
int Sum(int a, int b)
{
return (a +b);
}
I thinkm this is what you want to say by 'console application'. So, yes, you can simply export functions that will be called in your VB app.
yup, you're right.
I tried to use ATL but I found more complicated for beginners who just want to call VC functions. Does it support CString parameter? because, I'm quite surprised that ATL-based function parameters are not allowed to use them.
Thanx for your help
|
|
|
|
|
Do you know how to use the methods created in MFC dll into the VB prog? does it looks just like any other dll (ATL or COM)?
|
|
|
|
|
ATL and COM doesn't work the same. You cannot compare them, they are used for different purpose. So in COM you don't 'call' functions directly. Instead you use a control (like for example a chart control, a grid control, ...).
It is too long to explain in detail how to work with dll's. Better look here[^], you will find some article that will be very usefull.
|
|
|
|
|
First you have to figure out how your app should be designed.
One single binary (*.exe) or multiple binaries (exes + dlls).
Second if you have decided to use multiple binaries you have to figure out how these binaries should be used, multiple exes, regular dlls and/or using COM.
Third you have to figure out which tool you should use, i.e. do you want to use native Win32 API or some frameworks that encapsulate the Win32 API such as MFC or ATL?
All those abbreviations...
COM, Component Object Model, is in short a technique to distribute functionality in modules. COM doesn't have anything to do with the chosen programming language.
MFC, Microsoft Foundation Classes, is a framework of C++ classes that encapsulates the native Win32 API. Can be used for developing COM components.
ATL, Active Template Library, is a framework of C++ templates that encapsulates the Win32 API. Can also be used for developing COM components. In fact the letter 'A' in ATL stands for Active as in ActiveX, which is a specific part of COM.
benjnp wrote:
I'd like to create a program that has a VB interface but the functionalities came from VC
OK. You have decided that your application should consist of multiple binaries.
I wonder why because you do not appear to know how to achieve this and you said that are in a hurry. Perhaps you should give this one another thought.![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
However, multiple binaries could be the preferrable way to do this, it depends on your reasons. Keep in mind that a COM component could be considered a black box that solves a problem, e.g. serial communication (MsComm32.ocx); how that box looks inside is irrelevant for the one using it.
To me, given the circumstances you have described, the single binary solution should be the best choice. Pick the language you are most familiar with; if it's VB, then use VB. I would prefer VC++ and MFC. It's not that hard to create a GUI with MFC.
If this doesn't help or seems way of the topic, post again and describe why you have chosen the design you described and what functionality you want to keep in a separate module and why.
Hope this helps
--
Roger
|
|
|
|
|
I have already created a console app created in VC/MFC. We have to work in pairs and my partner uses VB and I use VC and in order for us to create a working program that will involve the two of us, we have to use the two PL's. VB will take care of the GUI and VC be in charge of all the functionalities of the application.
Using multiple EXEs, I'm visualizing(based on the term) it as a program (.exe) in VC with a specific function which the VB will call upon the click of the user of a certain button on the VB interface. Once the user clicked a function/button, the VB code will call ShellExecute to execute the corresponding exe file (created in VC) to perform the tasks. That's my idea of what you call multiple exe but it could be wrong.
Using DLLs, I was able to try creating a dll file by using atl wizard in VC and found out that the output dll can be called by VB but I wonder if I'm heading the right way regarding using the VC functions in VB bec moments ago I found it hard to use CString as a parameter to the method or even a property and I'm not even quite sure if it really supports CString and since I used CString in my console version a lot and I doubt if I could read/write a string from/to a file, I think I should drop off the idea of using ATLs.
MFC dll is another option and that's what I'm going to study for right now and I hope this will be the right one.
Any comments/suggestions?
|
|
|
|
|
What I meant with "multiple exes" was one main exe, e.g. your VB app, and perhaps a few COM EXE servers. I wrote this as a possible technical solution in the sense that it can be done, but it might not be the best solution.
Using ShellExecute reminds me of the old days of MSDOS and this is really not a nice solution, in fact it's really bad.
I also wrote "multiple binaries" meaning one exe and one or more dlls, which would be a more suitable way for you to complete your task at hand.
A COM component could be a dll. If you create a COM component using the ATL wizard, you will end up with a dll that contains your object. An ActiveX control is in fact a dll, even if the extension is 'ocx'.
You are writing a lot about CString as if it was the core of your problem.
Forget about it! CString is a MFC C++ class and Visual Basic cannot handle it since it's VB and not C++! For string representation VB uses something called B-strings, aka BSTR.
VB can only handle types that can be respresented with a VARIANT data type.
I recommend that you read more about it in MSDN.
I still haven't understood what you mean by "the functionalities of the application" that you want to handle in VC++.
It seems to me like splitting the code in one VB part and one VC part creates more problems for you than necessary.
However, if splitting the code is one of the goals in the project I suggest you create an ActiveX control using MFC for the VC part.
Below is what it takes to get you started with an ActiveX control:
Run the "MFC ActiveX ControlWizard" from DevStudio, choose a suitable name for your control, e.g. 'Cool' and in step 2 of the wizard check the "Available in 'Insert Object' dialog" checkbox and click 'Finish'.
Bring up ClassWizard and select the 'Automation" tab and click 'Add Method'.
Here you are forced to use only data types that can be handled by VB.
Choose a suitable name for your method, e.g. 'Test' and a return type, e.g. BOOL. Give the method a parameter called 'Text' and select LPCTSTR as the data type and click 'OK'.
You have now created an ActiveX control with an interface function called 'Test' that can be called from VB. I will tell you how in a minute.
It would be nice to see when the 'Test' function gets called so bring up the implementation file for your control; the file that ends with *Ctl.cpp and find the wizard generated function Test.
You will find that it takes a LPCTSTR called 'Text' as argument.
Show a message box when this function is called with the string 'Text' inside the message box with following statement:
MessageBox( Text, "From control", MB_ICONINFORMATION );
Build the project and you will have an *.ocx file in your debug directory which is your ActiveX component.
Now for the VB part:
Fire up VB and create a new standard EXE project.
Press <ctrl+t> and select your new component from the list and click 'OK'.
Add an instance of your control in the same way you add other controls such as buttons from the control bar. You'll find an 'ocx' control in the control bar.
Add a button to the interface and double-click it to add a handler for the click event. Call the 'Test' method of your component like this:
Cool1.Test "It works!"
Run the project and click the button and you should see a message box with the message "It works!".
A word of caution:
This is only a scratch on the surface, there's still quite a learning curve to be taken but this should get you started. This might not be the best technical solution, but this is what I consider to be the easiest way for you based on how I've interpreted your skills and needs.
Now you can add methods to the interface of your control that suits your needs that can be called from VB and you can write "the functionality of the application" in VC++. The instance of your control class will live for as long as the VB-app lives, which means that your member variables will keep their values between calls.
What you do here is a small part of COM using dispatch interfaces.
--
Roger
-- modified at 19:34 Tuesday 4th October, 2005
Forgot instructions for adding the control to the VB form.
|
|
|
|
|
First of all, I'd like to thank you and the forum for your time, learning somthing is much easier when you can ask directly from someone who knows about what your trying to learn.
Regarding CStrings, I noticed a BSTR type in ATL and gave it a try by:
STDMETHODIMP CFirst_ATL::.... (BSTR *strTemp)
{
*strTemp = "Hello World";
...
return S_OK;
}
error: cannot convert from char[6] to unsigned short*
I also can't find a variable type for a character (char MyChar for VC).
I think there's additional method regarding BSTRs, got to look for it.
MFC dll seems OK as I tried it just a few hours ago with simple application but haven't tried it yet when passing a string and other var types. I'll give ActiveX a try, i've seen a lot of .ocx ready for download because that's what my partner been using in his programs, but his using a pre-created .ocx from the internet and I never thought that it can also be created in VC.
Thanx again
|
|
|
|
|
Hi
I have a problem with a certain application which causes a runtime library error. This error is not frequently shown, the program can run about 3+ weeks non-stop, working perfectly .. sometimes it only lasts about 2 weeks.
When it crashes, i get an runtime error :
Microsoft Visual C++ Runtime library
Runtime Error !
Program: myprogram.exe
abnormal program termination
'OK'
I want to catch c++ runtime librarys errors and avoid having to click on the 'OK' button. The program is build in release-mode, so i don't understand why i still get that message. I thought this would only happen on debug-programs.
The program should crash & close yes, but not show any dialog. We monitor the program frequently & rerun the program automatically if necessary.
I know i should find the error first, but i shouldn't swear neither
Best regards,
Jens
|
|
|
|
|
Check how much memory is your application consuming while executing.
Check every day, Is it only incremental. Eventually your system will run out of memory and in some place you might have allocated memory (which failed) and written at that location which currupted certain memory area which is throwing that error.
or
you need you have a good logging info generated to figure out why and where it is failing.
-prakash
|
|
|
|
|
Hi,
i have already done that. The memory is not incremental, memory usages stays the same.
Catching std::overflow_error& exception, won't this catch the runtime exception and prevent the program from displaying the error?
Greetings,
Jens
|
|
|
|
|
The message looks to be getting generated via a call to "abort" which turns aronud and calls "_NMSG_WRITE". To change where this information gets logged, change the "__error_mode" to "_OUT_TO_STDERR" via a call to "_set_error_mode".
This will have to be done for the EXE and DLL that uses statically linked CRTL or just the EXE if everyone is linking dynamically to CRTL.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi, I want to customize FileOpen (CWinApp::OnFileNew), and FileSave dialogs such that they do not allow open or save files except spesific directory I give. Is it posisble to add this property?
|
|
|
|
|
You may need to derive a CXXXFileDialog from CFileDialog and show it by yourself when open or save.
Refer to MSDN's "CFileDialog". See the override functions. You can validate the path by overriding CFileDialog::OnFileNameOK() etc.
To handle open, you must write your own CXXXApp::OnFileOpen(). In this funcion, you can show your "open file" dialog and call OpenDocumentFile() to open the document(s).
To handle save, you must override CDocument::DoFileSave(). Perform you save operation after the save file dialog.
I'm not sure if this meets your goal.
Lane
China
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
