|
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?
|
|
|
|
|
Ali Tavakol wrote:
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.
IS Unicode is enable in your EXECUTABLE?, or you can try CreateWindowW to create Button
"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
|
|
|
|
|
Do not expect anything that is not in ASII to be displayed correctly.
There are articles in the MSDN on working with international languages as well as articles at CP. I think there may be an article at CP that mensions this subject, but I'm not sure.
I do not know if the latest book on iternationalization is include with the latest MS compiler. The old version of the book was include with VC6, but the newest version of the book just came out last year.
Now here's something you can try (experiment):
1) Set the locale to Arabic (you pick the country).
2) Get a handle to the button (or CWnd* in MFC).
3) Set the font for that button to an Arabic language font.
P.S.
I've been meaning to ask one of the guys from Irac or Iran to write an article on this subject. The MSDN article made me think that it will be as difficult (if not more so) as writting support for Asian countries.
Good Luck!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Hello Hi
What I am struggled with is:
I have written a program in VC++ (API) that uses farsi texts. this program runs correctly on my computer without I do anything with language settings (I only typed farsi text in dialog boxes in Visual C++).
but when I run this program on another computer (which has installed farsi language on english version of windows), farsi texts didn't show correctly.
what I should do, without using Unicode?
Provide me with some sample code if possible.
Thanks a lot.
|
|
|
|
|
Well, first I would have to write the code and second it probably would not help you.
Apparently you have realized that if you are using Unicode it will eliminate most of your internationalization problems.
First: You need to make sure that Farsi is one of your region settings for the computer you are running the program on (control panel->Region and Language Options).
Second: If you want to be able to display both languages, then you need to specify the locale (language) in your program or at least be able to determine what locale the user has specified and select a font accordingly.
Yes, I know it sounds complicated and it is. But there is an upside to this, if you just want to support (2 laguanges) Farsi and (ASCII) English, then you can just make sure that all your text drawing uses a Farsi font. The reason this should work, is that all character pages (as far as I know) have the ASCII (English) character set built in.
P.S. This is all (experenced) guess work here, as I have not written any code that specificaly targeted the Farsi language. I know there is an article here some where witten by a guy, who is a university student in Iraq, that may have a better understanding of what your problems are. Try to find him, as I am out of ideas (at the moment).
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Hi,
I've been trying to figure out how to open a file/url with the user's default browser but can't seem to find any info.
Is there a simple function like the "open" command of Mac OS X that opens whatever file you give it with the user's default program associated with that file type? Or will I have to muck around in the registry to find the correct program.
Thanks in Advance.
|
|
|
|
|
ShellExecute(NULL,"open","http://www.google.com",NULL,NULL,SW_SHOWNORMAL);
this is this.
|
|
|
|
|
khan++ wrote:
ShellExecute(NULL,"open","http://www.google.com",NULL,NULL,SW_SHOWNORMAL);
I Missed
"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
|
|
|
|
|
Thanks for the help guys, works like a charm!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
