|
it is
inline void Test::fun(void)
{
...
}
that gets link error (sorry for omitted Test: , still how to get rid of it?
9ine
|
|
|
|
|
have u define the inline function in .h file
|
|
|
|
|
|
sunit5 wrote:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/LNK2001.asp
Nice
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Hello all...
U also can do this...
in test.h:
#pragma once
class Test
{
public:
inline void doSomething(void);
};
#include "test.inl"
in test.inl:
inline void Test::doSomething(void)
{
// your code
}
works always fine...
best regards...;)
|
|
|
|
|
why? I had put my inline void Test::fun(void){ ... } from test.cpp file to the end of file test.h after Test class and link error disappeared. Is it really become inline?
9ine
|
|
|
|
|
why to put it in the end.u can define the inline function where its declaration is present ie.,
test.h
class Test
{
...
inline void func(void)
{//definition of inline function}
...
};
|
|
|
|
|
I am currently developing the server side applications for my project, my server user interface will receive a summary page wirelessly from the Client(Pocket PC) using CConnectedSocket, the summary page consists of name of the foods and qty of the foods ordered, number of drinks ordered, desserts ordered as well as the table number of where the customer is seated, my difficulties is how to program some intelligence in my server whereby the server can display the total number of the accumulated foods and drinks and desserts ordered? I am using Visual Studio .NET to develop this server's side application. Pls help..its really very urgent and i would very much appreciated anyone's help becos i have been stuck by this problem for days already..
|
|
|
|
|
Is it possible for a CWnd to clip child wnd's to a clipping region determined by the parent. Normally children are clipped to client area, but how can I reduce this area?
Simple is beautiful
|
|
|
|
|
Jesper Knudsen wrote:
Is it possible for ... clipping region determined by the parent.
That's called the client area.
You need rethink your question, because the answer is yes. But first you need to know what the question is.
INTP
"The answer to the question: Life the universe and everything is 42. But, what is the question?"
|
|
|
|
|
Question is, how can I reduce the client area?
Simple is beautiful
|
|
|
|
|
Jesper Knudsen wrote:
Question is, how can I reduce the client area?
That can not be the question, because the answer to that question is to reduce the size of the window.
As far as I know you can not reduce the client area without reducing the size of the window. You can however reduce the area you can draw in. But be careful, because if you do not draw in the area you ignore, then no one else will either.
I could write a whole book on this subject, but before I can answer a question on this subject I need to know what the actual question is.
1) Do you want to limit the window to a specific shape.
2) Do you just want to draw in a particular rectagular region or some other type (shape) of region.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
I have got at CWnd that add's CEdit's to itself. Parent draws a grid, in where those CEdit's are placed. The parent also has a scrollbar to the right, so that I can move my edit fields up and down. The parent draws a header row on top, but I don't want to have the cedits drawn on top of the header as I scroll up and down. So I want to create a 'clipping region' inside my client area, in where child cedits are allowed to draw themselves.
Hope this helps? Thanks for your time 
Simple is beautiful
|
|
|
|
|
:-DNow was that so hard?
Off the top of my head you have two choices: (1) Draw the headers after you have drawn the grid (you'll see some flicker, not a good thing), (2) Draw the headers first and exclude them (ExcludeClipRect(...)) from the drawing region, before doing any more drawing. In any case, only invaidate the areas where an actual change has occurred (not the entire window).
The drawing is the simple part, it gets more complicated after that (of course you know that already).
There is a Grid control (by Chris Maunder) at CP that you can study (or use). Many peaple at CP have contributed to it and it is free.
What you appear to be working on is what I call fun and what employers call a waste of resourses, if they know you're reinventing the wheel (don't educate them).
Good Night!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Hard hehe, I shortened my question for experts to take their time to actually read the question. Left out the details on what this was for, because I know that I'm actually re-inventing a huge wheel here - but it's a whole lot of fun!
Yes drawing the parent is the simple part, and it's all handled already (on a memdc without flicker) I know how to use clipping regions while drawing, but they won't clip child cedit's - and that's what my question is all about.
So it's not a question on how to code a grid control, it's far more simple:
Is it possible to clip child wnd's to a rect defined by a parent?
Simple is beautiful
|
|
|
|
|
Hehe, even experts cann't read minds.
When I see clip, I automaticaly see drawing. This seems more of a positioning problem, of course you still want to make sure it only draws in a specified area (clipping region). I would draw the cedit first, then excluded it from furthur drawing and draw the surrounding area.
If you havn't looked at that grid control (aka. spread sheet control), then take a look. The best answer to your question is barried some where in that code.
Good Luck!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Flash back! I just remembered doing this about 11 years ago (Win31). I just drew the grid and when the user clicked a the cell, that was supposed to be and edit control, I created a subclassed control on the fly at the location specified by the cell position. It worked just fine, the control its self had no border to worry about. When the user clicked any where outside the cell, the control window would self destuct (it was written in C) and the cell would redraw using the text that had been entered into the edit control. There was a little fittiling with calculations for proper positioning, but that's a minor detail.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Yes, this is excactly what I'm doing. When the user clicks a cell, I create a new cedit and places it at the cell position. Trouble is vertical scrolling - the newly created cedit will draw on top of (instead of beneath) the header row drawn by the parent.
I took a look at Mauders grid control, but you'll notice that he scrolls in steps of 'row height', so he can hide the entire cedit instead of clipping it.
I'd like smooth scrolling (pixel by pixel), so it's possiblt for the cedit to be partly hidden beneath the header row.
Usually child wnd's are clipped to the parents client rect. Eg you can create a new cedit at location CRect(10,-10,100,10) and it will be partly hidden.
CRect cr;<br />
GetClientRect(&cr);
always as (0,0) as upper left corner, and 'size-of-cwnd' as the lower right corner. This client rect defines the clipping rect to which child cedits are clipped. And this is the rect I want to modity by eg:
cr.top += HEADER_ROW_HEIGHT;<br />
ClipChildrenToThisRect(&cr);
Kno' I mean?
Simple is beautiful
|
|
|
|
|
Holly cow! No wonder you have been having problems!
It honestly never occured to me to scroll a grid by less than a line size (at least, not that I remember). Personaly I would not do it, accept as an exercise (fun). But if that is what you want, then you need to split the header row and the actual grid into seperate windows. That way, your cell drawing has no effect on you header drawing at all and if you scroll the grid, you do not not need to redraw the header.
Note: If you have a column header (most likely), then it would also have to be split into anouther window for the same reason (accept when scrolling (up/down) you'll have to scroll it too!).
The splitting of headers into sperate windows should have no effect on your file format, since they are only indirectly related.
If (for some strange reason) you wanted to be suburn, then you would have to override the drawing of the edit control completely, as I know of no way to modify the DC it is using internaly (before it actualy draws on it). Even if you could do that the caret would still overlap the header, even if the edit control did not.
Note: It can be done, but it is way to complicated and not worth the effort.
Addendum:
Even with smooth scrolling, you normaly scroll by a whole line; you just do it slower. What that means in this case is that when the user scrolls: (1) destroy the control (after saving the contents), (2) scroll the window one pixel at a time (redrawing after each) until a whole row has been scrolled.
Well, this post is long enough (I tend to get carried away).
INTP
Rem: If you can think of it (coding wise), then you can probably do it; but you have to decide if it is worth doing.
|
|
|
|
|
I tried creating such a header-wnd already. This approach has three additional problems:
1) the header and the actual grid dowsn't draw excactly at the same time (even if they're invalidated at the same time), so the header seem to be 'ahead' of the grid when resizing columns.
2) the header leaves a blank space in upper right corner of the grid control, above the vertical scroller. Notice file explorer has a scroller all the way up to the top.
3) too much housekeeping with who's actually owning the 'columns'. The header should simply know so much about the grid, that it might aswell be the same window.
My next strategy is as follows:
Create a header-cwnd yes, but leave it 'blank', that is without drawing anything with it. Pass all mouse messages on to the grid ctrl. Let the header and the cedit have the CLIP_SIBLINGS flag, and they'll clip against each other. Clumsy yes - but it's the only solution I can find to my question: "how to clip child windows to a clipping region defined by the parent?"
- Holy cow
Simple is beautiful
|
|
|
|
|
Hi all
I don't understand how windows messages are sent to a window procedure.
suppose my program is now in the process of answering a WM_CHAR message. now the user resizes the window. so Windows sends a WM_PAINT message to the window procedure. and while the program is answering WM_CHAR message, the window is repainted. what is the matter.
when does Windows send messages to the Message Queue and when does Windows send messages to the window procedure directly?
How is the order of messages sent to message queue?
Can the window procedure process two or more messages at the same time?
any answer is appreciated.
|
|
|
|
|
Until the WndProc returns, the rest of the messages remain in the queue. If the program is in the process of answering WM_CHAR message, like a long loop, the user will not be able to resize the window, even the sizing cursor will not appear.
The order of messages, I think is first-come first serve.
Ali Tavakol wrote:
Can the window procedure process two or more messages at the same time?
I think a second message cannot be received until the first one is done.
this is this.
|
|
|
|
|
Hi, thank you for your answer.
But this is not right. you can write a programm, and trap WM_CHAR in it and send the user a Message using MessageBox, if the user dosn't answer the message box but resizes the parent window screen, it will be repainted. also you can step into program (F10) to see how messages are sent.
but about order of messages: I know only that WM_QUIT message is sent to the begin of Message queue (not to the end)
|
|
|
|
|
Actualy khan++ is (basicaly) correct!
Sending a message to the user via MessageBox() has nothing to do with sending messages such as WM_CHAR, within your application. Opening another window (or dialogbox, in this case) has nothing to do with sending command messages in the current interface thread. If you can resize the parent window of a message box while the message box is still open, then the window you are resizing is probably not the parent window of the message box (because a message box is modal).
Here is an important point: When you post a message it goes into the message que, when you send a message it is sent directly. What that means is that if you're processing a message and post anouther message it will be processed after you are done with the current message, if you send a message while you're processing the current message, then it will be sent directly (bypassing the message que). Therefore, you need to be carefull as to when and where you send messages, inorder to prevent locking up your program.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Dear,
I am a C++ Windows API programmer.
I am now writing an arabic program that has some buttons which their text should be in Arabic language.
I created buttons with CreateWindow() function using the "Button" stock class and I wrote its name in Arabic languge. but the text didn't dispay correctly in arabic language.
what I should do?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
