|
Hello all,
I am trying to assign a Dialogbox resource to a custom dialogbox class... specifically Anna Meltcafe's CNGWizard (Resizable Wizard)
To be very specific, I have to make my PropertySheet belong to CNGWizard class and PropertyPages to CNGWizardPage class.
The problem is, I cannot locate CNGWizard nor CNGWizardPage in ClassWizard under MFC ClassWizard as the base class of the dialog.
It shows me CPropertyPage just fine, but does not have CPropertyPageEx !
I thought the .clw files had got corrupted again and rebuilt it, but CNGWizardPage nor CNGWizard appears in the controls list of the ClassWizard's "New Class" dialog...
I admit to never trying to use custom dialogbox classes before - but I have used custom controls a lot and custom control classnames showup in the ClassWizard just fine ?
I am using Visual C++ 6.0, SP5
-- modified at 22:03 Tuesday 25th July, 2006
|
|
|
|
|
As far as i can tell only the MFC base classes are listed in the wizard.
just derive the dialog from CDialog, include the cngwizard header, and change the
"class classname: public CDialog {"
to
"class classname: public CNGWizard {"
i have only ever replaced CDialog with base classes derived from CDialog.
|
|
|
|
|
Hey,
I have been converting a application from watcom/dos4gw/metagraphics over to vc++/MFC. i should mention that before i started (6 months ago) i had only programmed in basic and didn't understand c/c++ at all.
The program used to create a 3D model stored in an array, and then rendered it to the screen using a simple wireframe view and a sloooow BSP routine.
the hiddenline(BSP) functions are taken from a book written in the 80's and they are a complete mess, and for some reason run like 3/4 times slower on a 1500mhz windows machine than on a 350mhz DOS laptop?!? so anyway, instead of trying to understand this sytem and then converting it, i have created a DirectX Vertice buffer directly from the raw model Polygons. To create the buffers i adapted the old triangulation function to work with my data (without fully understanding it!), and then adapted a vector normal calculation routine from another (working) application.
To get a polygon triangulated correctly i have to rotate it twice, yaw then pitch, before the triangulation function finds any triangles, this is a copy of the vertice buffer the original is left unrotated. the function creates an array of triangles{A,B,C} that link to the vertice buffers. the vector normals are then calculated for each point in each triangle and a DX buffer is created.
After alot of hair pulling i finally got this to work however....
The Z buffer operation never works properly, objects behind are partially shown in front of other objects. i have tried all modes.
The Backface culling mostly works but removes some polygons that it shouldn't.
The lighting/shading is in oppposite directions for triangles in the same polygon.
Picture : http://www.rayevansengineering.com/Surreal/Conservatory.jpg[^]
I have no idea where the problem lies at the moment, after reading some stuff around the net i suspect it has something to do with the vector normals. or is it the fact that the point buffers are rotated for triangulation but not for rendering? maybe the triangulation function is arranging the points in some weird order?
Am i missing something else entirely? do the triangles in a polygon need merging somehow when creating the normals?
VECTOR NORMAL ROUTINE
vector1=pVertices[nOrigin].p-pVertices[nOrigin+1].p;<br />
vector2=pVertices[nOrigin].p-pVertices[nOrigin+2].p;<br />
D3DXVec3Cross(&temp,&vector1,&vector2);<br />
D3DXVec3Normalize(&pVertices[nOrigin].normal,&temp);<br />
<br />
pVertices[nOrigin+1].normal=pVertices[nOrigin].normal;<br />
pVertices[nOrigin+2].normal=pVertices[nOrigin].normal;<br />
<br />
PRE TRIANGULATION ROTATE
ang=geo.AngleXZ(newpoly.m_coord[p1],newpoly.m_coord[p2]);<br />
for (a=0;a<newpoly.m_npoints;a++) <br />
newpoly.m_coord[a].Rotate(newpoly.m_coord[p1],0,0,-ang,newpoly.m_coord[a]);<br />
pitch=atan2((newpoly.m_coord[p3].y-newpoly.m_coord[p2].y),(newpoly.m_coord[p2].z-newpoly.m_coord[p3].z))/RAD;<br />
pitch=-(90-pitch); <br />
for (a=0;a<newpoly.m_npoints;a++) <br />
newpoly.m_coord[a].Rotate(newpoly.m_coord[p1],pitch,0,0,newpoly.m_coord[a]);<br />
THE TRIANGULATION ROUTINE
[made the message huge] - can post if needed
-- modified at 21:38 Tuesday 25th July, 2006
|
|
|
|
|
Gnarley post! My first inkling would be that your triangles aren't drawn in the right order, i.e. clockwise or counter-clockwise, so maybe your Pre Triangulation Rotation function is suspect.
Don't know DirectX either, but in OpenGL, you can use the glRotate function to modify the current matrix, and then draw the object normally, without having to update the individual object vertices.
- S
50 cups of coffee and you know it's on!
|
|
|
|
|
i think you may be right. without rotating most of the polygons are clockwise and the triangulation function can't handle them(finds 0 triangules). that must mean that the rotations turn them counter-clockwise. the vertice buffer is copied to do the triangulation so the original polygons are left clockwise. So i guess Direct X is then rendering counter-clockwise triangle points linked to (wholly or partially)clockwise polygon coordinates.. hhmmmm...
|
|
|
|
|
I have some drawing code that seems to work *most of the time*. Trying to use some of this code today, I've encountered all sorts of odd behavior, and I'm questioning how I originally implemented this code. What I need from people who are deeper into Windows than I is the "why" of how painting/drawing in Windows actually works.
My app is dialog based. Some of the dialogs have to update graphics as fast as reasonably possible. So, early in my Windows development curve, I crafted my solution like so:
myclassdlg::OnInitDlg()
{
// set everything up...
// start a timer...
SetTimer (999, 500, NULL); // every 500ms
}
myclassdlg::OnTimer()
{
// do all of my drawing.
}
Now, based on various bits and pieces I've pulled together, this is just the wrong way to go about it. Unfortunately, it worked the first time, for whatever reason, and I've continued on my perilous ways. Well, now I've run into a problem, my new drawing code (based on the above style) doesn't work, so in my research, it appears that the correct way to do things is to start the timer but in the OnTimer loop, add an UpdateWindow() call to trigger the WM_PAINT message. The OnPaint handler than executes whatever drawing is necessary.
First question: do I have this right?
Second question: assuming I have this correct, what does the "draw in the OnPaint handler" apprach imply? It would seem that "this is the way you do it", but why? Does Windows do something special such that the graphics are guaranteed to draw?
Still getting my arms around this beast called Windows.
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
|
|
|
|
|
Im no expert but I think using the timer is incorrect. Have a look at these functions /messages in MSDN
InvalidateRgn
WM_ERASEBKGND
WM_PAINT
The idea is that when something changes that requires the graphics to change you call invalidate region to tell windows that this area of the screen/window in now out of date. Windows sends the WM_PAINT and WM_ERASEBKGND message as part of the screen painting process but if you attempt to paint to the screen outside of this process unexpected results can occur.
Objects in mirror are closer than they appear
|
|
|
|
|
You're right in that OnTimer() shouldn't do drawing, but should call an API that will trigger a repaint. RedrawWindow() will cause the whole window to be redrawn, that's the quickest way, although not the best if your painting takes a while.
The reason why is because Windows keeps some data about each window that indicates which part is "invalid" - meaning it needs to be redrawn. BeginPaint/EndPaint - which you call indirectly by using a CPaintDC object - do the bookkeeping that updates that data. If you just paint in some other random message handler, what you draw will get wiped out if another window covers yours.
So it's not so much that Windows guarantees that graphics will be drawn, but it guarantees that you will be notified (via WM_ERASEBKGND and WM_PAINT) when some part of the window has been uncovered, which is when you decide what to draw.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
Josh/Mike,
Okay, pieces are coming together. But, to belabor the point (because I really want to understand), Josh, could you elaborate on "but it guarantees that you will be notified" in the context of dialog/window creation? My perception is that sometimes my OnTimer approach works just fine, while at rare times I get nothing... or the wrong results.
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
|
|
|
|
|
You could try this experiment. Set the timer interval to a larger value, say 5 seconds SetTimer (999, 5000, NULL);. Then take a smaller window and move across your window a few times.
When your window is being uncovered as you drag that smaller window, windows will notify you using WM_PAINT that you need to redraw a portion of your window (the invalidated portion). Windows doesn't remember how your window is painted (ie. doesn't store what you painted previously), so it has to ask you.
|
|
|
|
|
hfry,
I don't seem to be communicating clearly - sleep deprevation most likely. I understand your test case. As I move windows, paint events should arrive. I understand this. What I'm trying to get a handle on is the dialog creation / paint notification sequence of events. Why such a restrictive situation you ask? The answer lies in my target application - it is a touchscreen and all window navigation is under program control.
In my specific situation, I create my dialog and initiate periodic updates to the screen. 99% of the time, this works like a charm. I happen to be in the 1% zone, and the window just won't paint correctly. I've reduced my code to attempting to blit a single, red-filled bitmap. The code is below. What I see on the dialog is WHITE when the red should be. If I change the FillRect call to go directly to the dialog DC, it draws correctly.
In my dialog, I do this:
OnPaint()
{
//CPaintDC dc(this); // don't need this, let drawing class deal with it.
UpdateDisplayData(); // Render the graphics.
}
....
In the drawing code (no, the class' name is not this silly...), I have culled out 99% of my code, reducing it to a single bitmap fill and blt:
CDisplayData::UpdateDisplayData()
{
CPaintDC dcDialog(m_pParentWindow);
CDC dcBitmap;
BOOL bStatus = dcBitmap.CreateCompatibleDC(&dcDialog);
ASSERT (bStatus);
CBitmap buffer_bm;
CBitmap *old_bm;
// Create an offscreen bitmap for antiflicker buffering...
bStatus = buffer_bm.CreateCompatibleBitmap(&dcBitmap, 100, 100);
ASSERT (bStatus);
old_bm = dcBitmap.SelectObject(&buffer_bm);
// Fill the bitmap with an arbitrary color, and copy it to the screen.
// "RED" is a macro...
dcBitmap.FillSolidRect(0, 0, 500, 100, RED);
bStatus = dcDialog.BitBlt(rc.left,
rc.top,
rc.Width(),
rc.Height(),
&dcBitmap, 0, 0, SRCCOPY);
dcBitmap.SelectObject(old_bm);
}
-- modified at 7:17 Wednesday 26th July, 2006
|
|
|
|
|
charlieg wrote: I'm trying to get a handle on is the dialog creation / paint notification sequence of events
I'm actually not too sure what you mean by this.
charlieg wrote: What I see on the dialog is WHITE when the red should be.
I suspect that that is because you are not handling WM_ERASEBKGND and the default handler is drawing the background (using the background brush which is usually COLOR_WINDOW which is usually white). And that it's not painting red because that region was not invalidated. This is of course just a guess, from the available code.
I notice you are double buffering to reduce flickering. Are you also handling WM_ERASEBKGND and doing nothing but returning 1? Are you "erasing" your window in your UpdateDisplayData() function (bitblting the background color)? Or is this not neccessary in your case.
In your OnTimer handler, do you invalidate the part of your window that needs to be redrawn (or the whole client area if that is the case)? You shouldn't be calling UpdateDisplayData() in your OnTimer handler as CPaintDC (BeginPaint()/EndPaint()) should only be used in response to a WM_PAINT message.
Windows maintains the clip region for your window when you need to do your painting, so if you don't have anything within the clip region (ie. didn't invalidate explicitly or windows didn't invalidate anything for you) then it's not going to actually draw anything to the screen.
|
|
|
|
|
hfry,
hfry wrote: I'm actually not too sure what you mean by this.
What I'm trying to understand is the initial dialog/window creation sequence and the ramifications on drawing. In a galaxy far away called Unix, they have this beast called X-Windows. A drawing 101 error was trying to draw before something called an expose event. Drawing before this results in all of the drawing going into the bit bucket. Fast forward to today - Windows has it's own little mechanism called the invalid region - if you don't invalidate things, they won't draw. Now, most of my drawing codes does not invalidate anything, it just starts blasting away, and the images show up. My theory is that when a dialog/window is created, everything is invalid, and my drawing appears... just a theory. So, that's why I'm asking how things really work - maybe there is something more subtle.
Okay, so getting to your specific comments:
1) WM_ERASEBKGND - with a couple of very unique situations, I never handle this.
My drawing code regenerates the image in a bitmap. The BitBlt then replaces
the entire region on the window. My rationale was, why bother to erase
something that I'm getting ready to paint over?
FWIW: I added a handler for this message - no effect.
2) As far as "erasing my window" - I simply call InvalidateRect with the same
CRect that I use in the drawing code. Note this this is just the test code
I'm running now. Usually, I do not do an invalidate operation, electing to
draw out of the OnTimer handler. Both *seem* to work (but I have my doubts
 ).
Even with relocating the code to the OnPaint handler, the only time the
screen is updated correctly is when I draw directly to it. If I use the
code to fill a bitmap then blit the bitmap, I get white.
I truly appreciate your suggestions and patience. This issue has me a bit 
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
|
|
|
|
|
OMG!!!
I just found it, and I understand why superficially, but I think my way should have worked. Ignore all the onpaint comments, not directly relevent to the behavior at hand.
Broken code / working code is bolded below.... Now, does someone want to explain to me why I have to create a compatible bitmap from the PaintDC? Is it not logical that if I create a buffering DC with CreateCompatibleDC(PaintDC) should not a bitmap created be compatible as well?
CDisplayData::UpdateDisplayData()
{
CPaintDC dcDialog(m_pParentWindow);
CDC dcBitmap;
BOOL bStatus = dcBitmap.CreateCompatibleDC(&dcDialog);
ASSERT (bStatus);
CBitmap buffer_bm;
CBitmap *old_bm;
// Create an offscreen bitmap for antiflicker buffering...
bStatus = buffer_bm.CreateCompatibleBitmap(&dcBitmap, 100, 100);
bStatus = buffer_bm.CreateCompatibleBitmap(&dcDialog, 100, 100); // this works
ASSERT (bStatus);
old_bm = dcBitmap.SelectObject(&buffer_bm);
// Fill the bitmap with an arbitrary color, and copy it to the screen.
// "RED" is a macro...
dcBitmap.FillSolidRect(0, 0, 500, 100, RED);
bStatus = dcDialog.BitBlt(rc.left,
rc.top,
rc.Width(),
rc.Height(),
&dcBitmap, 0, 0, SRCCOPY);
dcBitmap.SelectObject(old_bm);
}
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
|
|
|
|
|
|
Okay, I'm going to go off on a little rant here... the method is called CreateCompatibleBitmap, for God's sake! So the documentation clearly calls out that the bitmap created ISN'T compatible - that makes me feel better?
I think it should be renamed as CreateMostlyCompatibleBitmap()
The only thing worse than no doc is erroneous doc.
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
|
|
|
|
|
charlieg wrote: What I'm trying to understand is the initial dialog/window creation sequence and the ramifications on drawing.
You could try using a spy application like this[^] to look at the kind of messages that windows generates for your application.
charlieg wrote: theory is that when a dialog/window is created, everything is invalid
Yes when your window is created everything is invalid.
charlieg wrote: WM_ERASEBKGND - with a couple of very unique situations, I never handle this.
When windows sees that there is an invalid region (and there are no more messages on the queue) it will generate 2 messages, WM_ERASEBKGND and then WM_PAINT. Windows paints the entire invalid client area with the background brush for you if you choose not to explicitly handle WM_ERASEBKGND.
Windows flicker for 2 reasons. One is when it takes too long to draw and you're drawing directly to the screen, then you can see windows drawing your window piece by piece. The other is when the window gets invalidated too quickly, ie, you keep having a lot of WM_ERASEBKGND and WM_PAINT messages in succession. The default window procedure (if WM_ERASEBKGND isn't handled and you don't return a non-zero value) will paint the entire client area with the background for you. This is usually undesirable if you are trying to eliminate flicker as you first have a white screen, then what you painted, then white again, etc, causing flicker.
charlieg wrote: Usually, I do not do an invalidate operation, electing to draw out of the OnTimer handler
The problem with this is when your window gets obscured and uncovered by another window. In which case windows will generate a WM_ERASEBKGND and WM_PAINT message. If WM_ERASEBKGND is not handled, the invalid area is painted with the background brush for you. If WM_PAINT doesn't do anything, then you just have the background. If you handled WM_ERASEBKGND and elected not to do anything and WM_PAINT isn't doing anything, then you are left with whatever bits happen to be there on the invalid area of your window. Of course if your timer is fast and you keep painting to the screen, it's unlikely that you'd really notice anything amiss.
|
|
|
|
|
All of your comments are dead-on. I'll be going back to clean up some sins of the past next week. Since my timers fire rather rapidly, and my drawing is buffered, the user never notices anything... until I have to slow the timers down ...
I appreciate all your help. I still want to slap silly the CreateCompatibleBitmap coder.
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
|
|
|
|
|
Well, it probably means that the function is creating a bitmap compatible to the bitmap selected in the device context that you passed in. Yeah kinda bites, I'm also guilty of assuming what functions do based on their names instead of checking the docs. 
Raymond Chen's blog[^] is a good read if you don't know about it already.
|
|
|
|
|
I have a CString variable that has a port address that needs to be converted to an unsigned short....I'm using the _outp(short, int) to communicate to an i/o port. I tried doing a 'atoi' on the string, but I end up with a 0.
For the second part I would like to convert the address(short) back to a string.....
I apperciate the help.
Thanks,
-------------
CString test = "0xF03";
test.Remove(' " '); //Remove the quotes
unsigned short x = atoi(test);
_outp(x,0x81); //Need this to be _outp(0xF03, 0x81)
|
|
|
|
|
arunkk1 wrote: test.Remove(' " '); //Remove the quotes
Unless you actually have CString test = ""0xF03""; there are no quotes to remove.
arunkk1 wrote: unsigned short x = atoi(test);
atoi() does not understand integer strings written in anything other than base 10.
Use strtol() instead.
unsigned short x = strtol(test, NULL, 16);
Convert back
test.Format("0x%X", x);
|
|
|
|
|
Hello,
I have developed an application that uses a bitmap associated with a static control using CStatic::SetBitmap. When displaying the image in the client area:
1. I would like the ability for the user to select an area of interest (via a transparent rectangle).
2. Be able to move and rubber band the rectangle similar to CRectTracker. The rectangle should not be able to be moved or resized out of the CStatic client window.
3. Report the coordinates of the rectangle with respect to the client area coordinates (i.e. top left, bottom right).
Does anybody have Visual C++/Studio sample code that would do this?
Thanks in advance,
PJP
|
|
|
|
|
sub class CStatic class and then on mouse events u update the window in Onpaint handler.
Sudeesh
|
|
|
|
|
I have a solution that contains several projects. Most of these projects use files that are common between them all.
I would like to only have the common files in one place so that I only have one version of them. Thus if one of the common files is changed all of the projects that use it will be updated/compiled again.
Any help with this would be very much appriciated.
Thanks,
Jim
|
|
|
|
|
Put all your common files in one directory, and set your projects to look in that directory. Configuration Properties >> C/C++ >> Additional Include Directories. Or you could set it in VC++ Directories.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
