|
The only syntactic difference is that static_cast won't compile if CYourApp isn't derived from CWinApp, which is highly unlikely. It's just my personal preference to cast the C++ way.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Hi Tomasz,
Thank you for your explain ...
Now, can you write example about using of m_db from AfxGetApp() ?
Because in your example you use of GetDatabase() in AfxGetApp(), now can you write example about using m_db in AfxGetApp() ?
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
AfxGetApp() (if I rememeber right)is a gobal function in MFC which returns a pointer to your CWinApp derived class so you can use "->GetDatabase()" Any public function in this CWinApp derived class called from dialog(other class also outside this discussion) can be called this way.
|
|
|
|
|
In all honesty, I don't feel that exposing your db as a pointer or a reference is the best design. I think it would be far better to simply put the db in the mainframe class (or possible a doc class) and have a means of communicating data back and forth between the db and the UI by some sort of intermediate set of classes.
i.e.:
class CSomeDBData // or a struct if your prefer.
{
//whatever
};
CMainFrmame::OnSomeCommand()
{
CMyDialog MyDlg;
CSomeDBData somedata;
m_db.GetSomeData(&somedata);
MyDlg.EditSomeData(somedata);// or however you like.
if( MyDlg.DoModal() == IDOK )
{
MyDlg.GetSomeEditedData(somedata);// or however you like.
m_db.SetSomeData(&somedata);
}
}
This way, you don't end up with pointers and references to your core objects scattered all over your application. Which, as the application grows, will certainly happen unless you take steps to limit it. If your app is large you should concentrate on keeping data centralized and not globally available to anything that might need to access it or which might store pointers to it. This takes a little extra work, but pays off in the long run.
|
|
|
|
|
Hi,
Thank's it was nice help ...
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Hi again Stan,
Your idea was very good, but i have little problem ...
I can check the return value of DoModal() for checking the hited button ...
But when i click on button in the dialog, dialog will close !!!
Now, i want to use of button in the dialog in CManFrame class without dialog will close ...
How can i do that ?
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
First, I have never used the DAO classes (I typically use CDatabase/CRecordset for simple stuff and ADO for anything else). So I cannot address issues relatiing to DAO specifically. There may be easier techniques for you to use than what I am suggesting for DAO built into MFC. If you look at MSDN or Codeproject samples you might find something relating to that.
Yes, DoModal returns when the dialog box is closed. That is by design, and is typically the behavior you want. Obviously, I don't know the details of your design, and maybe what I'm suggesting will not work for you. All I'm saying is that it is the approach I *always* take, as I have found it to be a very safe and simple way to do business, especially in a large application that many people have their hands on.
What I am suggesting is that you copy the data that you want to manipulate from the db object, which is "owned" by the MainFrame object, to the dialog box, initializing the dialog box with that data (there are various opinions about how to do that best). Next you allow the user to manipulate that data in the dialog box. Finally, if the user hits OK you copy the edited data from the dialog box and back to the db object, if the user hits cancel, do nothing at all.
In this way, the dialog box never needs to know that the db object even exists, and the db needs to know nothing about the dialog. Only the Mainframe window (and the db object itself, of course) knows, or cares, about the db object, or the dialog. In this way, the db object, and whatever global data it contains, is not made public to the entire application unnecessarily.
If the db data also needs to be accessed from objects other than dialogs, (views, for example), than that might be an argument for giving ownership of the db object to your document class rather than the Mainframe. If more than one document/view needs access to the db data, well, than you might need to consider letting the App class handle it afterall. As the programmer, its your call.
|
|
|
|
|
I want to use CGfxOutBarCtrl class, but I need to display an icons with variable width (height is permanent) in it.
All icons are adding via CImageList but it stretch all of them to the maximal size.
Do you have any ideas how to display such type of icons there?
With the best regards, Vitaly.
|
|
|
|
|
You would have to use two, or more, imagelists. As you found out everything in the imagelist must be the same size, that is how individual images are found, by calculating the offset based on the size.
|
|
|
|
|
i would use the ADodb method to create a link between an vc++ application and Access 97. what is the correct microsoft jet OLEDB i need to use, 4.0 or 3.51?
gerald
|
|
|
|
|
Access97 uses 3.51, but 4.0 should be backward compatible.
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
I have editBox (read only) with spin.
the variable of the editBox is int in range 10 - 2000
and the range of the spin is same.
and all is right.
But when the user try to up the number in the editBox over 999
he gets a error messageBox: "Please enter an integer."
WHY ?????????????????????????????????????????????????
Please HELP
|
|
|
|
|
Uncheck the No Thousands property of the spin control - this prevents the control from adding a thousands separator (period or comma) to the number.
--Mike--
http://home.inreach.com/mdunn/
Push the button, Frank.
|
|
|
|
|
Thanks on the quickly answer !!!
|
|
|
|
|
I have gray the desktop, but there still some area cannot be grayed, how can I gain this effect.
I use CreateDIBSection. and BitBlt to copy the memory dc to the desktop.
|
|
|
|
|
I have try to gray the desktop when my program runs. by there are still some problems:
1, If I use CreateDIBSection, What bitsperpixel should I use, 8, or >8?
2, If I can use 32bits, even on 16 desktop settings?
|
|
|
|
|
hi.. I wanna open a folder from my software...Can i do that??????
|
|
|
|
|
I don't know exactly what you mean, but try looking up
SHBrowseForFolder in the MSDN Lib
maXallion "Look for bugs, I hate bugs!" - Warden, The Mummy www.maxallion.de - coded evil & more
|
|
|
|
|
I have two different times on my box...In VC++ the time says "1:40" and in the System Tray it says "8:40"?? Even when I write a program using the System time in VC++ I get the C++ time and NOT the actual System Time??
Settings:
Region(Locale)/Keyboard: U.S.
Time Zone: Germany (-1)
The funny thing is this is the Time (-7 hours) as our Mother Company in the US. I hope someone can show where the problem is.
Thanks in advance,
Dan
|
|
|
|
|
You don't say what function you use to get the time, but if you use time(), you have to convert the time with localtime() to get the local time...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Does anybody know the way to get rid of the thick (client?) border around the edit portion of combo box? Regular methods (that work with other controls) seem to have no effect.
Trying to make a property list control.
Thanx,
Dejan,
Melbourne
|
|
|
|
|
The example of a code, which one is fine draws on a screen, but is absolutely failed to print (except for a framework of an rectangle).
CTestView::OnDraw(...)
{
CBitmap m_bitmap;
m_bitmap.LoadBitmap(IDB_ ...);
CBrush m_brush;
m_brush.CreatePatternBrush(&m_bitmap);
CBrush * pSysBrush = pDC->SelectObject(&m_brush);
pDC->Rectangle(0, 0, 300, 300);
pDC->SelectObject(pSysBrush);
}
How to make correctly?
|
|
|
|
|
When you print you'll be working with a much bigger DC than on the screen. It probably printed a dot somewhere near the top. You need to query the printer DC to find out it's size and then scale the bitmap accordingly.
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.
|
|
|
|
|
I want to add a Capture Video ActiveX in my program.
When I add the ActiveX in my mainframe (CMyAppDlg) and that I use the associated functions with this activeX, I don`t have any problem.
But I want to add this ActiveX in a modeless windows created by a item menu. The problem is when I include this ActiveX in my modeless windows and that I call the associated functions to the ActiveX, I have a Assertion Error: "Debug Assertion Failed!" in the file "Winocc.cpp" for each call of a function of this ActiveX.
So, I don't know why the ActiveX work in my mainframe but doesn't work in the modeless Windows since I use the same code in the two manner?
Thanks for your help!
Francis B.
|
|
|
|
|
I'm having the same problem with a different ActiveX control I'm using
in a modeless dialog from within a DLL. For some reason it seems as though
the ActiveX control is not being created properly during the call to
Create(). Mine always has a NULL hWnd after the call to create so whenever
a method on the control object gets called it bombs out with that same
assertion error you're getting because the control has actually not been
created properly. I wish I had a solution for you, this one is driving
me crazy!
|
|
|
|