|
thank you! Do you have the code of LineTo? Mine is much slower than the CDC::LineTo. And how to create a pen with square cap in win98?
thanks to all the programmers who have helped me.
|
|
|
|
|
Do you have the code of LineTo? Mine is much slower than the CDC::LineTo.
Why do you need your own LineTo?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Hi, I have programm in VB, where is transparent window. And I rewrite code to MFC. But i have problemm  ((. I dont know why ?!, but i see only black color on screen .
Can you help me ?? Here is my code.
_________________________________________
void CMyDialog::DrawScreen(CDC* dc){
CDC *window=GetDesktopWindow()->GetDC();
CDC *drawing = new CDC;
CBitmap *bitmap = new CBitmap;
CBitmap* oldbit;
drawing->CreateCompatibleDC(window);
bitmapa->CreateCompatibleBitmap(window,1050,1004);
oldbit = drawing->SelectObject(bitmap);
dc->BitBlt(0, 0, 100, 100, drawing, 1000, 730, SRCCOPY);
drawing->SelectObject(oldbit);
}
________________________________________
LB
|
|
|
|
|
You're trying to blt from uninitialized bitmap selected into the 'drawing' variable. Can't you just use the 'window' DC as a source?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Can you write my the code ?
Please .
lb
|
|
|
|
|
Ohhh, I have it. But : when I use BilBlt--> programm display the picture. And this picture is dialogwindow of programm . But i need picture which is unter the window ?? How can i do it ??
|
|
|
|
|
But i need picture which is unter the window ?? How can i do it ??
What worked OK in your VB program?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
This is code from program in VB :
Function hDCToPicture(ByVal hDCSrc As Long, ByVal LeftSrc As Long, ByVal TopSrc As Long, ByVal WidthSrc As Long, ByVal HeightSrc As Long) As Picture
Dim hDCMemory As Long, hBmp As Long, hBmpPrev As Long, R As Long
Dim hPal As Long, hPalPrev As Long, RasterCapsScrn As Long, HasPaletteScrn As Long
Dim PaletteSizeScrn As Long, LogPal As LOGPALETTE
'Create a compatible device context
hDCMemory = CreateCompatibleDC(hDCSrc)
'Create a compatible bitmap
hBmp = CreateCompatibleBitmap(hDCSrc, WidthSrc, HeightSrc)
'Select the compatible bitmap into our compatible device context
hBmpPrev = SelectObject(hDCMemory, hBmp)
R = BitBlt(hDCMemory, 0, 0, WidthSrc, HeightSrc, hDCSrc, LeftSrc, TopSrc, vbSrcCopy)
hBmp = SelectObject(hDCMemory, hBmpPrev)
R = DeleteDC(hDCMemory)
Set hDCToPicture = CreateBitmapPicture(hBmp, hPal)
End Function
Private Sub Form_Load()
dsk = GetDesktopWindow()
'Create a picture object from the screen
Screen.TwipsPerPixelX, Screen.Height / Screen.TwipsPerPixelY)
srcdc = GetDC(dsk)
Set Me.Picture = hDCToPicture(srcdc, Left / Screen.TwipsPerPixelX, Top / Screen.TwipsPerPixelY, Width / Screen.TwipsPerPixelX, Height / Screen.TwipsPerPixelY)
End sub
Function CreateBitmapPicture(ByVal hBmp As Long, ByVal hPal As Long) As Picture
Dim R As Long, Pic As PicBmp, IPic As IPicture, IID_IDispatch As GUID
'Fill GUID info
With IID_IDispatch
.Data1 = &H20400
.Data4(0) = &HC0
.Data4(7) = &H46
End With
'Fill picture info
With Pic
.Size = Len(Pic) ' Length of structure
.Type = vbPicTypeBitmap ' Type of Picture (bitmap)
.hBmp = hBmp ' Handle to bitmap
.hPal = hPal ' Handle to palette (may be null)
End With
'Create the picture
R = OleCreatePictureIndirect(Pic, IID_IDispatch, 1, IPic)
'Return the new picture
Set CreateBitmapPicture = IPic
End Function
|
|
|
|
|
It seems that you're trying to copy the desktop window to a bitmap first. Next, you want to display a dialog and paint its background using saved image. There's a class encapsulating a memory DC and a bitmap on code project; search for CMemDC.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I would to monitor the memory usage as given in the taskmanager , i would be more helpful if some one provide the solution .
GG
|
|
|
|
|
|
Hi all,
I'm writing program about database,
In my program i have three dialogs, and i have to use of CDaoDatabase object in all dialogs ...
I want to use of only one object for do that,
How can i do that ???
Does i must create global variable ?
I mean, writing CDaoDatabase g_db; in first of my source code, and using of extern CDaoDatabase g_db; in other cpp files ???
Do you have any idea ?
My program is in SDI mode ...
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
Make your CDaoDatabase an application data member and provide an accessor function in your app class...
class CYourApp : public CWinApp
{
public:
CDaoDatabase& GetDatabase() { return m_db; }
private:
CDaoDatabase m_db;
};
... and use AfxGetApp in your dialogs to get access to db:
CDaoDatabase &db = static_cast<CYourApp *>(AfxGetApp())->GetDatabase();
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Hi Tomasz, and thanks for reply ...
Can you explain more about your source codes ...
For example, first, you make private member variable CDaoDatabase m_db; and then you make public member function CDaoDatabase &GetDatabase(){return m_db;} !!!
WHY ???
Why you make GetDatabase() function ? why i shouldn't use of only m_db ?
And please explain to me how can i use of GetDatabase() function ...
Because i'm beginner ...
Thanks again ...
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
For example, first, you make private member variable CDaoDatabase m_db; and then you make public member function CDaoDatabase &GetDatabase(){return m_db;} !!! WHY ???
This is called encapsulation. The main benefit is that you can rename m_db and you'll have to change the name only in two places 
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Hi again,
AfxGetApp() is object of CWinApp class, so can't use of m_db or GetDatabase() in AfxGetApp() !!!
My month article: Game programming by DirectX by Lan Mader.
Please visit in: www.geocities.com/hadi_rezaie/index.html
Hadi Rezaie
|
|
|
|
|
|
Actually, Tomasz, I would not mind having an explanation of the advantage of static_cast over the old fashioined ((CMyApp*)AfxGetApp())->WhatEver() in this case.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
