|
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
|
|
|
|
|
jparken wrote: Can you shed any light on this 'anomaly'?
By far the most common cause of this, and it is not an anomaly or problem with the enviroment or C++, is misuse of assert.
led mike
|
|
|
|
|
Thanks, guys, for the responses.
John P.
|
|
|
|
|
What function in MFC will be called and discnnect the view from the document?
|
|
|
|
|
|
I have a console app that reads and writes from a virtual comport pair.
It works great when only one instance of the program is running. But when I execute another app that opens a different virtual comport pair, I get some strange errors. I have tried different (brand) virtual comport devices, resulting in the same effect.
Once I enter data on the comport for the second application to read, the first app will respond erroneously. The second app fails to perform as it should as well.
So my real question: Do console apps share memory space somehow? These are not threads but separate processes.
Any help is appreciated.
Thanks.
|
|
|
|
|
switang wrote: So my real question: Do console apps share memory space somehow? These are not threads but separate processes.
No, but the virtual com port might be doing so.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
I never have any problems when using terminals to connect between the comports. I'd rule out the virtual ports as the culprit. I've used two different virtual devices (com0com and VSPD).
I have noticed that entering data in the input com of one app causes the other app to respond as if it received data.
I'll have to try this setup on another system to rule mine out.
|
|
|
|
|
switang wrote: I never have any problems when using terminals to connect between the comports.
What I meant was that it might create the same buffer for multiple connections. Thus, if you have 2 programs opening a virtual port to talk to each other, and then you open another instance of each program, depending on how the virtual com ports are implemented (e.g. if they are a COM service), they may be considered the same session, or may try to use the same buffers.
switang wrote: I have noticed that entering data in the input com of one app causes the other app to respond as if it received data.
So if you enter data in 1 of the apps, both the app you expect to received the data and the app you don't expect to receive it are getting it? If that is the case, it would seem to indicate what I said above (and that the virtual port isn't thread-safe).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
It's beginning to look like a problem with my system. If I figure something out I'll try to post.
Thanks for the input.
|
|
|
|
|
I am modifying a MFC based C++ application which I have migrated from VS6 to VS8. Several months ago I was surfing the Internet and came across a forum post somewhere (I can't remember where) that described oring together two button styles I recall (BS_PUSHBUTTON, etc.) which generated a button that looks like a tab with rounded corners on the top and flaired corners at the bottom. This apparently was an undocumented feature of VS. I, in fact, modified the dwStyle parameter of a button creation and was able to observe it generate this tab-like shape. I mentally filed away this interesting feature as possibly useful in the future -- big mistake as I forgot the details. I now have a project that needs exactly such a button shape and cannot recall the details or how to generate it. Is there a programmer out there that can tell me what dwStyle parameters can be used to generate this tab shaped button.
|
|
|
|
|
Hello all
Are you concerntating?
Yes, good. I am wondering it anyone knows the answer to
this topic or can point me in the right direction.
I'll elaborate upon my query. Thus any replies I get
(hopefully), will be answeredin the correct context.
Below are is a sample three controls.
- A standalone control (Demo control 1)
- Another standalone control (Demo control 2)
- A meta control which has its own features as well as
containing controls (1 & 2 above)
When I build the first two, they both build and register successfully. I can
use either (or both) on other projects as child windows. i.e. VC dialogues, VB
forms, Delphi Forms. Web pages ect. with no problems.
There seems to be a problem when ActiveX control is a parent.
The nature of my
query is this: how can achieve no3 (meta control) Without
it causing crashes when I insert it into other projects (or the test
container) Step by
step to what I did to create number 3:
- I've designed a control for called CMetaCtrrl via
AppWizard
- Inserted both Demo1 and Demo2 ActiveX controls into the project with their
wrapper classes generated
- Added a member 'variables' to both
- Inserted the handler WM_CREATE (that's what you have to do if you're using
child windows)
- Inside the function OnCreate. I've added code to allow creation of the children windows
CRect rcInit(CPoint(0), CPoint(0));
m_demo1.CreateControl(m_demo1.GetClsid(), "", WS_CHILD | WS_VISIBLE,
rcInit, this, 1001);
m_demo2.CreateControl(m_demo2.GetClsid(), "", WS_CHILD | WS_VISIBLE,
rcInit, this, 1002);
- Added code to position and make Demo controls 1 &
2 visible
- Built the project (Which it does successfully) also
favourably accomplished is the registration of the control.
That done I test newly created control. It's when I insert that's when the
troubles start. When using the test container it raises an execption, or on
placement of the control on a form (or dialogue) the same things happens.
In addition to that it brings down whatever development tool I'm using. The
problem is occurring when an attempt is made to create the first chold
window.
On debugging I've stepped into m_demo1.CreateControl().
Which leads me to step into
AFX_MODULE_STATE* AFXAPI <br />
AfxGetModuleState() the module state is not a NULL pointer.
I then went to probe into
CMetaCtrl::InitControlContainer() (BOOL CWnd::InitControlContainer()). The issue
behind it is coming from the fourth line of the snippet
(m_pCtrlCont = <br />
afxOccManager->CreateContainer(this); ) 
<CODE>
TRY
{
if (m_pCtrlCont == NULL)
m_pCtrlCont = afxOccManager->CreateContainer(this);
}
END_TRY
</CODE>I fail to understand why this is happening. I know how to place
common controls a child on an ActiveX control. I would like to know how to
create and place an ActiveX child and have another as it's parent. Surely, there must be a way
of doing this. I'm sorry this is so verbose, I had to explain it such
a way that I will get my question in it's correct context.
Many Thanks Alton
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
