Is it possible to draw on dialog
-
I am very sorry yah I am passing only hadle and pointer to RECT. I found that handle from ID.But Problem is there,as I used this fnction so many times It works fine.
|| ART OF LIVING ||
I can't imagine what the problem is. Maybe a bit of debugging on your end will help? Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
-
Why draw on the dialog? Why not draw in your own window that is a child of the dialog? Of course while drawing on a dialog it's a good time to eat your Fish Filet Actually I am not sure he needs to draw, maybe just use a static control and put some text in it, hard to say from his post. I think he really needs[^]
Was it a joke or anything. No doubt my total VC experience and total experience is 1.5 years , and Basically I am Mechanical Engineer, but right now I am developing FingurePrint Identification Server For ATM Parallel to Main Switch for Identification Aplab India, Near CheckNaka, Thane(W), Maharshtra India -400604. I am putting in joke to bypass from main discussion.
|| ART OF LIVING ||
-
Why draw on the dialog? Why not draw in your own window that is a child of the dialog? Of course while drawing on a dialog it's a good time to eat your Fish Filet Actually I am not sure he needs to draw, maybe just use a static control and put some text in it, hard to say from his post. I think he really needs[^]
I am not that master of VC ,but I have to work on very higher end. I need to show somehow how many atms ,which all atms are currently running. Doubt is lack of Life force , Answers cannot satify doubt Only Art Of Living Can Solve www.artofliving.org
-
I am building application as secondary identification server for ATMs. My application is fine. But just for pictorial representation I want to show ATM line on dialog who alls thread is currently active. I am planning to show on dialog it self. (Or I have to develop separate ActiveX for doing so,please suggest) while showing on dialog , I am not getting crash of GetWindowRect and device context of dialog window may not proper.It crashes at ::GetWindowRect Of groupbox in which I was planning to show the running threads. I am not sure why crash is occuring. I am not sure devicecontext I can obtain.
|| ART OF LIVING ||
shivditya wrote:
It crashes at ::GetWindowRect Of groupbox in which I was planning to show the running threads.
"show the running threads" what does that mean? Show them how? If you just want to display some text put a static control in side the GroupBox control and then SetWindowText on the static control.
-
shivditya wrote:
It crashes at ::GetWindowRect Of groupbox in which I was planning to show the running threads.
"show the running threads" what does that mean? Show them how? If you just want to display some text put a static control in side the GroupBox control and then SetWindowText on the static control.
No not like that. Just like bar graph I said Group Box Because ,I Just kept groupbox to have some border around Graph. And I was taking its rect because I was willing to have some Base coordinates.Which ATM is running ,graph line will be shown for it on y axis. And ATMs will be on X axis.
|| ART OF LIVING ||
-
No not like that. Just like bar graph I said Group Box Because ,I Just kept groupbox to have some border around Graph. And I was taking its rect because I was willing to have some Base coordinates.Which ATM is running ,graph line will be shown for it on y axis. And ATMs will be on X axis.
|| ART OF LIVING ||
shivditya wrote:
Just like bar graph
Ok then you definitely don't want to draw that on a dialog that has other controls on it. You want to make your own window and draw the graph in there then that window is placed on the dialog as a child like other controls are. If you are using MFC you just derive from CWnd then in the dialog you setup the window as a child using whats called "subclass"ing. Have you looked at the C++ articles here on CodeProject. I would imagine there are some that walk you through all of this. There is probably even a article with code that will draw the bar graph for you.
-
shivditya wrote:
Just like bar graph
Ok then you definitely don't want to draw that on a dialog that has other controls on it. You want to make your own window and draw the graph in there then that window is placed on the dialog as a child like other controls are. If you are using MFC you just derive from CWnd then in the dialog you setup the window as a child using whats called "subclass"ing. Have you looked at the C++ articles here on CodeProject. I would imagine there are some that walk you through all of this. There is probably even a article with code that will draw the bar graph for you.
Thanks I will Search for it. Conclusion 1) Drawing on dialog is not so easy. 2) Subclassing will help // I dont 3) Can diretly add classes which are already developed. Will you please redirect me to what exactly you mean by placing child window on dialog. class CDerived : public CMyMainDialog { -------- }; CMyMainDialog cm = new CDerived() cm.Domodal();
|| ART OF LIVING ||
-
Thanks I will Search for it. Conclusion 1) Drawing on dialog is not so easy. 2) Subclassing will help // I dont 3) Can diretly add classes which are already developed. Will you please redirect me to what exactly you mean by placing child window on dialog. class CDerived : public CMyMainDialog { -------- }; CMyMainDialog cm = new CDerived() cm.Domodal();
|| ART OF LIVING ||
-
Thanks I will Search for it. Conclusion 1) Drawing on dialog is not so easy. 2) Subclassing will help // I dont 3) Can diretly add classes which are already developed. Will you please redirect me to what exactly you mean by placing child window on dialog. class CDerived : public CMyMainDialog { -------- }; CMyMainDialog cm = new CDerived() cm.Domodal();
|| ART OF LIVING ||
shivditya wrote:
Conclusion 1) Drawing on dialog is not so easy. 2) Subclassing will help // I dont 3) Can diretly add classes which are already developed.
- Drawing on a dialog is just as easy as drawing on any window. It's just not a good solution beyond maybe drawing a custom background. 2) You're using MFC - the subclassing is done for you if you use CWnd as a base class.
shivditya wrote:
what exactly you mean by placing child window on dialog.
Every control on your dialog is already a child window of the dialog. It seems logical, then, if you need an area of the dialog to draw in then you should use a child window to do so. You can place your child window on the dialog just like you'd use a child window anywhere - 1) Implement the window class, or use an existing window class, perhaps 3rd-party code 2) Create a child window object of that class 3) Create the Windows object (HWND) for the window object, using the dialog window as the parent
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
-
shivditya wrote:
Conclusion 1) Drawing on dialog is not so easy. 2) Subclassing will help // I dont 3) Can diretly add classes which are already developed.
- Drawing on a dialog is just as easy as drawing on any window. It's just not a good solution beyond maybe drawing a custom background. 2) You're using MFC - the subclassing is done for you if you use CWnd as a base class.
shivditya wrote:
what exactly you mean by placing child window on dialog.
Every control on your dialog is already a child window of the dialog. It seems logical, then, if you need an area of the dialog to draw in then you should use a child window to do so. You can place your child window on the dialog just like you'd use a child window anywhere - 1) Implement the window class, or use an existing window class, perhaps 3rd-party code 2) Create a child window object of that class 3) Create the Windows object (HWND) for the window object, using the dialog window as the parent
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder