|
You can use a join as: "SELECT * from table_one,table_two where table_one.column=table_two.column"
Therefore Overload the GetDefaultSQL() function of CDaoRecordset and return "table_one,table_two"
|
|
|
|
|
Hi,
Please explain more about your source code,
And please explain: if i want to write record table1 ? how can i ?
because now i have two table !!!
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Hi,
I'm having a rather weird problem here and I thought that maybe, if I described it, it would ring some bells with the experts. I haven't a clue!
Anyway, here's the situation:
We have an in-house developed database-access layer with all kinds of specific goodies in it and for reasons of deployment and ease of upgrade, we isolated it in an MFC extention DLL.
This all worked fine for a couple of months. I can integrate it easily in existing programs and everything works fine... that is, as long as I integrate it in an exe!
The database-access layer in the DLL has a feature which displays a tray-icon. You can see what the layer is doing by looking at the tray-icon's color or by calling a dialog, hidden in the tray-icon's context menu. Of course the dialog and tray-icons are all located in the resource of the extention dll...
As long as I integrate the extention dll in a stand-alone application (.exe), everything works fine, tray-icon included. But when I integrate the dll in an activeX-component (complete with clsid and interface) the tray-icon's icon cannot be loaded from the resource! In release build this results in a tray-icon without an icon (just an empty space) which isn't THAT bad, but when I try to bring up the dialog it fails completely (which you might expect). In debug build I get all sorts of assert-failures saying that the icon HANDLE is invalid...
So how come everything works fine in a stand-alone application and it fails in an ActiveX component? 
Structured programming vs. chaotic mind boggling
|
|
|
|
|
use AFX_MANAGE_STATE(AfxGetStaticModuleState()) in your DLL.
see MFC technical note 058 for more info
if it doesn't help, you can set the resource handle manually in the DLL
HINSTANCE hResPrev=AfxGetResourceHandle ();
AfxSetResourceHandle (GetModuleHandle (_T("CT.DLL")));
...
AfxSetResourceHandle (hResPrev);
|
|
|
|
|
MFC Extension DLL will work correctly only if your exe is also MFC app linking dynamically to MFC. With ActiveX, your .exe is a container - you can't expect all apps hosting your ActiveX to be MFC apps.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I'm trying to write a dll that when fed a process ID, displays the UDP ports the process is using/resources process is consuming.
How can I do this? any articles/code, links would be useful.
TIA.
I'm an alien, I'm an alien
it's a beautiful life....
Bush
|
|
|
|
|
Hi!
For quick info check http://www.sysinternals.com , especially Source and Information links on the site.
Regards,
Gennady
|
|
|
|
|
Hi all,
I've got one question here about the installshield.
How do I know what dll should I insert into my installshield program??
Now I try to create one installshield for my application. I copied all the
dlls needed but I'm not really sure whether they are correct or not. When I
try to install the application it works fine but it automatically dispose
the dialog box. This is happen when I install in a new pc ( with no visual c++). However, when I
tested on my pc ( which got visual c++), the application works fine. My
application is a dialog based application which using thread.
Thanks in advance. 
Regards,
Farah
FMansor
|
|
|
|
|
If you are asking what files you need to run your program then you can use the program Depends which comes with VC++. It will show you which files your program requries.
If you're asking what files you need to run install shield then read the documentation. There's a section on distributing your install program.
When you say "automatically dispose the dialog box" do you mean it closes automatically right after you start it? If that's the case then there could be lots of reasons it's failing. I suggest running a debug version of your app on your other system.
|
|
|
|
|
Say I have DialogX with its code compiled into xstuff.dll. How would I open this dialog from an application such as getx.dll.
Thanks
-Matt Newman 
|
|
|
|
|
Opps. I forgot to say I am working with MFC in both.
-Matt Newman
|
|
|
|
|
You would need to export a function in the dll to display the dialog, then use it.
One method (not actual code):
LoadLibrary(getx.dll)
GetProcAddress(DispalyDialog)
Call method to display dialog
|
|
|
|
|
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Installshield really sucks. What do other people use?
By chance, does a demo project of a simple installation package exist anywhere? I would really like to create an intallation package, but i don't want to start from scratch. I am hoping to adjust and modify other code to make it work for my project.
Please, any repsonse any one can give me will be greatly appreciated.
My email address is brinasas@yahoo.com
Sincerely,
Danielle
|
|
|
|
|
We use Setup Factory and it rules. It's cheap and it's simple to use.
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
|
Perhaps you could be more specific then "Installshield really sucks". I've usually found that comment from people who don't understand how to use it. What version are you using? What don't you like about? What problems are you having?
|
|
|
|
|
But it DOES really suck! Here's why:
1) Each installation requires a large tree of folders, each with uncountable binary files. Just try checking that into a source control system. Well-designed installers, such as Wise, use a single file.
2) It is ridiculously hard to learn. Again, compare to Wise.
3) It is buggy as hell. Need I repeat myself here?
4) The stupid progress control it sets up in the lower right corner of the screen. Ugly and uninformative. Yes, I know it can be disabled, that's why this is #4 instead of #1.
|
|
|
|
|
We have managed to overcome these deficiencies and Installshield works well for our case. You don't seem to understand it and think it is something it is not.
Once you take the time to learn it properly and try to work within it's limits, not the way you think it should work, you may have more constructive feedback than "it sucks"
If you think Installshield is difficult stay away from Windows Installer.
|
|
|
|
|
Customizing dialogs etc. can be a major pain in the arse.
It leaves files in your temp directory. I've seen people unable to install a program because they exceeded the file limit for that directory. It was full of install shield temp direcotries.
If the scripting language doesn't meet your needs then you're kinda screwed.
Supporting multiple languages is costly.
I'm not a big fan of install shield either.
Todd
|
|
|
|
|
Customizing dialog is not very difficult if know what your doing.
Leaves temp files. Yes, but I have seen that behavior from many other applications also.
If the scripting language doesn't meet your needs extend it with a custom dll. Can't get much better than that.
Yes they charge large fees for additional languages.
|
|
|
|
|
Wise, DanYell. www.wisesolutions.com
|
|
|
|
|
I would like my program to remember the state of a few check boxes and radio buttons from the previous time it was run. How can I accomplish this?
Also I would like the program to open in the same position as it was closed from the previous run.
|
|
|
|
|
The registry or an ini file. I'd go registry, but some people prefer to put the data in a local file. My reasoning is that this is what the registry is for, and I like my state information to by hidden from the majority of users. The other side reasons ( quite reasonably ) that too much junk goes into the registry. So the choice is yours.
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
|
The registry is good for that - as long as you don't put too much in it. Usually you'll see code in InitInstance (after the call to SetRegistryKey) that calls GetProfileInt (or whatever) to retrieve settings (which can then be set to the dialogs members), and WriteProfileInt calls in ExitInstance that store tham back.
Or you could use an .ini file, or persist to file. There may be religious opinions about this! 
|
|
|
|
|
I also store simple state data in the registry even though I do not like the way MS implemented the registry. (Concept is good, implementation is bad). The most important thing to consider when storing data to the registry is the probability that the user may want or need to edit that data. It is generally a VERY bad idea to store user configurable data in the registry. If they accidentally edit/delete the wrong thing they will hate you forever. Use an ini file for user editable configuration data.
|
|
|
|
|
John
the following code works if you are using a dialog based application, place the SetWindowPos() function in OnInitDialog() and GetWindowRect() function in OnOK or another function that gets called before the dialog closes. You would then need to read/write the values to the registry or ini file.
CRect rect;
GetWindowRect(&rect);
int nLeft = rect.left;
int nTop = rect.top;
SetWindowPos(&wndTop, nLeft, nTop, 0, 0, SWP_NOSIZE | SWP_NOZORDER);
Michael Martin
Pegasystems Pty Ltd
Australia
martm@pegasystems.com
+61 413-004-018
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
