|
You need some design changes. We don't have enough information yet to help much with that.
led mike
|
|
|
|
|
Okay, I'l try my best to describe the problem more precisely. Before I go into further details, this is an implementation of a scene graph holding a quad tree, something used in graphics programming in order to arrange elements in space to avoid sending unnecesary data to the graphics card.
First of all there's CScene, which represents the scene graph. CScene holds a tree of nodes and functionality for inserting in that tree and manipulating it. Since this tree can hold a lot of diffrent types of nodes, I need to just define a very loose interface for the minimum required functionality of a node that needs to be implemented ( such as Update, Render, AddChild etc ). That interface is called CNodeInterface. When CScene is created it will create the upper elements of the tree with CQuads, this is to create the quad tree. This is how it could look for example:
ROOT
|
|---Quad 1
| |
| |---Quad 1.1
| |
| |---Player
| |
| |---Sword
|
|---Quad 2
|---Quad 3
|---Quad 4
|
In order to save space I've left out nodes under Quad 2, 3 and 4 as well as 3 sub quads under Quad 1. Player and Sword implements CNodeInterface.
Thankful for any help 
|
|
|
|
|
From your desrciption it sounds more like you need a polymorphic style layout rather than cyclic. Try deriving your classes from a common base class, then pass a pointer to the base class around rather than the derived classes. Again, without seeing exactly what you are trying to do it's kinda hard to give you advice.
|
|
|
|
|
Ylis wrote: First of all there's CScene, which represents the scene graph
That does not provide enough context to understand the purpose/roll/responsibility of CScene
Ylis wrote: I need to just define a very loose interface for the minimum required functionality of a node that needs to be implemented ( such as Update, Render, AddChild etc )
It does not seem that AddChild belongs in the same type as Update and Render. Your QuadNode should likely be a template container then you might have an interface containing the Update and Render methods and then you would implement QuadNode root node (your tree) with the interface as the template parameter.
interface ISceneEntitiy
void Render( canvas or device context etc)
void Update(....)
tempate <class t=""> class QuadNode
{
// implements AddChild, Remove, and accessors, iterators for traversing etc.
}
then somewhere (we don't have enough information to know where)
QuadNode<isceneentity> _rootNode;
then you Player and Sword implement the ISceneEntity interface
Then you likely need some Creational Pattern to generate (populate) the tree. Then if the tree is mutable you likely need some Manager to contain the logic of change to the tree.
There might be much more than this but again we don't have enough information to go on.
led mike
|
|
|
|
|
This is probably a stupid question, but is there any sort of time restriction on processing windows messages? In particualar the WM_PAINT and related messages?
I'm seeing some really strange behaviour with my window. I have 3 skinned static controls, each is an instance of exactly the same class. All message processing and function calls are identical. The only difference is the size and position. The control at the bottom of the window is failing to recieve WM_PAINT message while the window is being resized. Or I should say, failes to recieve messages when the main window is of a certain height.
here is the output from spy++
<00865> 0038085C S WM_WINDOWPOSCHANGING lpwp:0012E3B0
<00866> 0038085C R WM_WINDOWPOSCHANGING
<00867> 0038085C S WM_CHILDACTIVATE
<00868> 0038085C R WM_CHILDACTIVATE
<00869> 0038085C S WM_WINDOWPOSCHANGED lpwp:0012E3B0
<00870> 0038085C S WM_MOVE xPos:14 yPos:105
<00871> 0038085C R WM_MOVE
<00872> 0038085C R WM_WINDOWPOSCHANGED
<00873> 0038085C S WM_WINDOWPOSCHANGING lpwp:0012E3B0
<00874> 0038085C R WM_WINDOWPOSCHANGING
<00875> 0038085C S WM_CHILDACTIVATE
<00876> 0038085C R WM_CHILDACTIVATE
<00877> 0038085C S WM_WINDOWPOSCHANGED lpwp:0012E3B0
<00878> 0038085C S WM_MOVE xPos:14 yPos:104
<00879> 0038085C R WM_MOVE
<00880> 0038085C R WM_WINDOWPOSCHANGED
<00881> 0038085C S WM_WINDOWPOSCHANGING lpwp:0012E3B0
<00882> 0038085C R WM_WINDOWPOSCHANGING
<00883> 0038085C S WM_CHILDACTIVATE
<00884> 0038085C R WM_CHILDACTIVATE
<00885> 0038085C S WM_WINDOWPOSCHANGED lpwp:0012E3B0
<00886> 0038085C S WM_MOVE xPos:14 yPos:103
<00887> 0038085C R WM_MOVE
<00888> 0038085C R WM_WINDOWPOSCHANGED
<00889> 0038085C S WM_PAINT hdc:00000000
<00890> 0038085C R WM_PAINT
<00891> 0038085C S WM_NCPAINT hrgn:84041466
<00892> 0038085C R WM_NCPAINT
<00893> 0038085C S WM_ERASEBKGND hdc:EE01123B
<00894> 0038085C R WM_ERASEBKGND fErased:False
As you can see, the window only start getting these messages after its position is less than 104 units. Does anybody know why this might be happening?
I should also point out that I am repositioning / resizing the window, and the messages only fail when the size is being reduced, there is no problem when being expanded. I have tried the repositing with both SetWindowPos() and MoveWindow() both giving the same results.
-- modified at 16:47 Wednesday 1st November, 2006
|
|
|
|
|
WM_PAINT is a low priority message. It will only be sent to a window when there are absolutely no other messages in the message queue. I do not know if this is what you are facing here as the 104 units thing is confusing. Without seeing the actual behaviour and code I can not tell you any more with the information presented.
|
|
|
|
|
Check that your main window's class styles include CS_HREDRAW|CS_VREDRAW. When you say you get no paint messages when making the window smaller, that's the normal behavior without those class styles - no portion of the client area is being revealed, so no painting is necessary.
|
|
|
|
|
Hi..
I've got a dialog window with horizontal and vertical scroll bars to move the window... That all works fine.. The only problem is I have some slider controlls inside the window that move it too.. and that isn't wanted..
I'm thinkin any time I move one of my slider objects.. it sends a message to OnHScroll(); or OnVScroll(); depending.
I only want the window scroll bars to send the message. Not the dialog slider objects
void CEdrumMonDlg::OnSize(UINT nType, int cx, int cy) //Creates the window scroll bars if the window size is changed
{
CDialog::OnSize(nType, cx, cy);
m_nCurHeight = cy;
m_nCurWidth = cx;
int nScrollMax;
int nScrollMax2;
if (cy < m_rect.Height())
{
nScrollMax = m_rect.Height() - cy;
}
else
nScrollMax = 0;
if (cx < m_rect.Width())
{
nScrollMax2 = m_rect.Width() - cx;
}
else
nScrollMax2 = 0;
SCROLLINFO si;
si.cbSize = sizeof(SCROLLINFO);
si.fMask = SIF_ALL; // SIF_ALL = SIF_PAGE | SIF_RANGE | SIF_POS;
si.nMin = 0;
si.nMax = nScrollMax;
si.nPage = si.nMax/10;
si.nPos = 0;
SetScrollInfo(SB_VERT, &si, TRUE);
SetScrollPos(SB_VERT,m_nScrollPos,TRUE);
SCROLLINFO si2;
si2.cbSize = sizeof(SCROLLINFO);
si2.fMask = SIF_ALL; // SIF_ALL = SIF_PAGE | SIF_RANGE | SIF_POS;
si2.nMin = 0;
si2.nMax = nScrollMax2;
si2.nPage = si2.nMax/10;
si2.nPos = 0;
SetScrollInfo(SB_HORZ, &si2, TRUE);
SetScrollPos(SB_HORZ, m_nScrollPos2,TRUE);
}
void CEdrumMonDlg::OnVScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar)
{
int nDelta;
int nMaxPos = m_rect.Height() - m_nCurHeight;
switch (nSBCode)
{
case SB_LINEDOWN:
if (m_nScrollPos >= nMaxPos)
return;
nDelta = min(nMaxPos/100,nMaxPos-m_nScrollPos);
break;
case SB_LINEUP:
if (m_nScrollPos <= 0)
return;
nDelta = -min(nMaxPos/100,m_nScrollPos);
break;
case SB_PAGEDOWN:
if (m_nScrollPos >= nMaxPos)
return;
nDelta = min(nMaxPos/10,nMaxPos-m_nScrollPos);
break;
case SB_THUMBPOSITION:
nDelta = (int)nPos - m_nScrollPos;
break;
case SB_PAGEUP:
if (m_nScrollPos <= 0)
return;
nDelta = -min(nMaxPos/10,m_nScrollPos);
break;
default:
return;
}
m_nScrollPos += nDelta;
SetScrollPos(SB_VERT,m_nScrollPos,TRUE);
ScrollWindow(0,-nDelta);
CDialog::OnVScroll(nSBCode, nPos, pScrollBar);
}
void CEdrumMonDlg::OnHScroll(UINT nSBCode, UINT nPos, CScrollBar* pScrollBar) //pretty much same as OnVScroll
|
|
|
|
|
I "think" pScrollBar is NULL if the message doesn't come from a scroll bar so maybe try
just returning from your OnHScroll/OnVScroll handlers if pScrollBar is NULL.
Mark
|
|
|
|
|
Awsome!
it's actually the other way around...
if(pScrollBar != NULL){return;}
Thanks again mark.
|
|
|
|
|
Hello,
i need your help again 
so, i am trying to create invisible window with MFC i will post my source code then you should understand more easily what a f**k i am trying to do  i know, i am doing something wrong  hmm.. so the main question is how to create invisible window?
***HookApp.cpp***<br />
<pre>#include "stdafx.h"
#include "HookApp.h"
HookApp theApp;
void HookApp::FileWrite(char *data)
{
FILE *f;
errno_t err;
err = fopen_s(&f, "C:\\debug.txt", "a");
fprintf(f, data);
fflush(f);
fclose(f);
}
HookApp::HookApp()
{
FileWrite("Constructed\n");
}
HookApp::~HookApp()
{
FileWrite("Destructed\n");
}
BOOL HookApp::InitInstance()
{
FileWrite("Initialized\n");
MyWnd* pWnd;
pWnd = new MyWnd();
WaitForSingleObject(HookApp::m_hThread, 10000);
return false;
}</pre><br />
<code>***HookApp.h***<pre>class HookApp : public CWinApp
{
public:
HookApp();
virtual ~HookApp();
virtual BOOL InitInstance();
static void FileWrite(char *data);
};
class MyWnd : public CWnd
{
DECLARE_DYNAMIC(MyWnd)
public:
MyWnd();
virtual ~MyWnd();
afx_msg LRESULT OnMsg(WPARAM wParam, LPARAM lParam);
DECLARE_MESSAGE_MAP()
};</pre><br />
<code>***MyWnd.cpp***<pre>#include "stdafx.h"
#include "HookApp.h"
#include "pKhook.h"
IMPLEMENT_DYNAMIC(MyWnd, CWnd)
LRESULT MyWnd::OnMsg(WPARAM wParam, LPARAM lParam)
{
HookApp::FileWrite("message\n");
return 0;
}
MyWnd::MyWnd()
{
HookApp::FileWrite("Invisible Window Constructed\n");
InstallKeyHook();
KEYENTRY m_entry;
m_entry.nMessage = WM_MY_EVENT;
m_entry.hCallWnd = m_hWnd;
m_entry.hHookWnd = 0;
m_entry.iCombKeys = 0;
m_entry.iIndicators = 0;
m_entry.iKeyEvent = 0;
m_entry.iMinVKCode = 0x00;
m_entry.iMaxVKCode = 0xff;
if(KH_OK == AddKeyEntry(&m_entry)) HookApp::FileWrite("KeyHook Init Done\n");
}
MyWnd::~MyWnd()
{
HookApp::FileWrite("Invisible Window Destructed\n");
}
BEGIN_MESSAGE_MAP(MyWnd, CWnd)
ON_MESSAGE(WM_MY_EVENT, OnMsg)
END_MESSAGE_MAP()</pre><br />
thanks for all of you in advance :)
|
|
|
|
|
edvintas wrote: so the main question is how to create invisible window?
My main question is "why" do you want an invisible window?
led mike
|
|
|
|
|
because i need to handle messages from *.dll which is using PostMessages method 
|
|
|
|
|
edvintas wrote: so the main question is how to create invisible window?
Windex?
Here's one way. In your invisible window class add this override function
BOOL CMyInvisibleWindow::PreCreateWindow(CREATESTRUCT& cs)
{
CWnd::PreCreateWindow(cs);
cs.style &= ~WS_VISIBLE;
return TRUE;
}
|
|
|
|
|
edvintas wrote: ...how to create invisible window?
By removing the WS_VISIBLE style. There's also ShowWindow(SW_HIDE).
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
|
so this is a problem that i am not sure how to create window message handling with MFC and i am not sure whether i should use CWnd or somewhat other base class 
could you give me a hint how what to do next after this: 
MyWnd* pWnd;
pWnd = new MyWnd();
what method should i use?
|
|
|
|
|
edvintas wrote: i am not sure how to create window message handling with MFC
Well if you don't actually want a GUI window then don't use MFC message handling. Override WindowProc and handle your messages in there. Of course you still need to "create" the window as Chris points out.
led mike
|
|
|
|
|
You would also need to call the Create() method in order to get a window and message handling all set-up. The next problem you are going to have though, is that whatever DLL you are trying to get messages from will need to be linked into your process or your window will never see the messages. Are you trying to hook into any DLL that may be posting messages or is the DLL linked into your app and it is posting messages to you?
Chris Meech
I am Canadian. [heard in a local bar]
Nobody likes jerks. [espeir]
The zen of the soapbox is hard to attain...[Jörgen Sigvardsson]
I wish I could remember what it was like to only have a short term memory.[David Kentley]
|
|
|
|
|
|
edvintas wrote: i suppose i have found something useful here...
The CWnd Class[^] docs are useful for understanding CWnd creation/destruction as well.
|
|
|
|
|
Hi, everybody:
I encounter a very strange behaviour between a release mode and debug mode of the program.
I use application wizard to create a win32 application. then add a modeless dialog to control something of a view. I use message from the modeless dialog to communicate with the view. in debug version, everything is fine. For release version, the first message is fine, when the second message arrives, I use GetDocument() function to return m_pDocument of the view, i found m_pDocument is NULL????!!!!!
Anybody can give me a clue on this?
When I debug the release mode, I found the m_pDocument pointer is NULL, but could not identify where it was changed?
If possible, I can upload the source code, you cn look it up.
Thanks a lot!
|
|
|
|
|
how jack wrote: Anybody can give me a clue on this?
It means that the view is not attached to a document.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
David --- how does that not show up in Debug (the view is not attached to a document)?
To me that is one of the most frustrating elements of VC++ 6.0. If it works in Debug, it should, by default almost, work in Release mode. Can you shed any light on this 'anomaly'?
Thanks
John P.
|
|
|
|
|
Exactly how is the modeless dialog communicating with the view?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
