|
look in help for main, wmain etc. - they return int
t!
|
|
|
|
|
Can you explain your answer ???
|
|
|
|
|
your program can look like this:
int main(void)
{
return 7;
}
calling .bat can work with it:
program.exe
if errorlevel 7 goto END
also you can do this:
void main(void)
{
exit(7);
}
it is better now?
t!
|
|
|
|
|
I have recently moved away from MFC, and focussed on Win32 programming instead. But I am having problems with safe drawing of DCs, particularly the SelectObject() and DeleteObject() functions. I know that whenever you create an object and select it, you must get the old object so you can put it back when your finished. I found some source code for this and it went something like this:
HBRUSH hbrNew = CreateSolidBrush(RGB(255, 0, 0));
HBRUSH hbrOld = SelectObject(HDC, hbrNew);
// Drawing Stuff...
SelectObject(HDC, hbrOld);
DeleteObject(hbrNew);
But this doesn't work with the compiler. It has a problem with the hbrOld being a HBRUSH. If anyone can help or tell me how to do it properly, it would be greatly appreciated.
James Bird - birdjames@bigfoot.com
|
|
|
|
|
SelectObject returns HGDIOBJ - you have to cast the return value to HBRUSH --or-- declare hbrOld as HGDIOBJ.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Correct. Either way you will have to use a cast:
method 1:
HBRUSH hMyBrush = CreateSolidBrush(RGB(255,255,255));
HBRUSH hBrushOld = (HBRUSH) SelectObject(myDC,hMyBrush);
//Draw Here
SelectObject(myDC,hBrushOld);
DeleteObject(hMyBrush);
method 2:
HBRUSH hMyBrush = CreateSolidBrush(RGB(255,255,255));
HGDIOBJ hBrushOld = SelectObject(myDC,hMyBrush);
//Draw Here
SelectObject(myDC,(HBRUSH)hBrushOld);
DeleteObject(hMyBrush);
|
|
|
|
|
Either way you will have to use a cast
Not true. Version 2 doesn't need a cast to HBRUSH
HBRUSH hMyBrush = CreateSolidBrush(RGB(255,255,255));
HGDIOBJ hBrushOld = SelectObject(myDC, hMyBrush);
SelectObject(myDC, hBrushOld);
DeleteObject(hMyBrush);
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Hi all,
I want to use of use of two table in only one CDaoRecordset object ...
Does i must use of two object ???
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|