|
You are on another pbm then.
Well, yes exactly, there's indeed not such "central" dock site or space within the FrameWndEx.
the FrameWndEx first lays out the docking panes, according to their positions in the borders and the central space that is left is reserved for the CView that would have been attached to the Frame and to another abstract CDocument class via the documenttemplate mechanism.
If you do'nt have time to adapt the source code then I think you just have to identify one of your existing docking panes and put its content into the CView, so it will be always shown in the central area and the remaining panes will be placed to its left/right/top, etc.
I hope your situation is not the same as mine in 2007 when I had to develop a video surveillance application. Docking panes (or control bars) seemed to be perfect to use as windows to show remote camera video and let the user manage the custom positioning of multiple video window byhimself.
There was the need to get rid of the central area. this was not possible since all my panes are in term of type of content the same. I ended up doing things manually inside the CView.
So I hope your pbm be solved by finding the particlar docking pane that hosts the type of content that can be shown persistently in the central area (CView). Otherwise also try to invent one !
Easy Profiler : a compile-time profiler for C++
www.potatosoftware.com
|
|
|
|
|
I am afraid my situation is similar to yours in 2007
Maybe it's even worst because I have to switch between a view modes (different sets of panes).
For example:
View mode1 ---> Pane1-Pane4-Pane6
View mode2 ---> Pane2-Pane3-Pane5
BTW:
Putting one of the panes into the view may be a good solution and I should consider it, but in this case I can already see a main problem: when you try to drag this pane out you came to the same situation of empty rectangle...
|
|
|
|
|
Well first of all let me also suggest to you to consider the use of splitter frame. It is also easy to use : all you have is to indicate the splitting(rows/columns) and then attach windows to each resulting zone.
You can make a toolbar on top of the frame with each button corresponding to a certain "split configuration" or "mode" according to your terminolgy.
Thus when the user choses a mode, you rest the splitting algorithm and dynamically reattach windows to the zones (This is allowed by the SplitterWnd).
Finally, commenting on your last note, well, you should note that a view can't be dragged out of the central space. You told me your application is SDI. If it was MDI and the docking panes are created within the main frame then if you do'nt have a child frame (CMDIChildFrameEx) then the central void will appear.
Easy Profiler : a compile-time profiler for C++
www.potatosoftware.com
|
|
|
|
|
Error while ending the thread, please advice
unsigned __stdcall TF(void* arg)
{
HANDLE timer=(HANDLE) arg;
while (1)
{
if(iStopPrgBar11==1)
{
_endthread(); // Error flashed @ this point
return 0;
}
WaitForSingleObject(timer,INFINITE);
prgBar->StepIt();
}
_endthread();
return 0;
---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!
Program: ...Client\aimNavigator\guiLayer\navigator\DebugMDd\navigator.exe
File: afxcmn.inl
Line: 449
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
(Press Retry to debug the application)
---------------------------
Abort Retry Ignore
---------------------------
|
|
|
|
|
Accessing some Invalid index would be a quick guess. Did you try using the great DEBUGGER to know where and why the assertion is popping up...
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
The line in the. pls advice,
What would be the cause
File: afxcmn.inl
Line: 449
AFXCMN_INLINE int CSliderCtrl::SetTipSide(int nLocation)
|
|
|
|
|
Why do you need the _endthread() call?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Have you looked at line 449 of afxcmn.inl ? That would be a big clue as to what condition is asserting.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Hi all,
I want to know how to set the window size in an sdi application to 770*550.After setting it to the desired size it does not have any scroll bars.Also where can I put the corresponding code.
please help,,
its urgent...
|
|
|
|
|
johnthecoder wrote: I want to know how to set the window size in an sdi application to 770*550.After setting it to the desired size it does not have any scroll bars.Also where can I put the corresponding code.
The SetWindowPos function changes the size, position, and Z order of a child, pop-up, or top-level window.
The scroll bars won't be visible if the application fits to the window. you can check this behavior with IE
johnthecoder wrote: its urgent...
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
It sounds like you may have a FormView application and your form is larger than the default window size. If that's the case, look in your view class at the OnInitialUpdate method. You can change
ResizeParentToFit(); to be
ResizeParentToFit(FALSE);
Hope that helps.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
|
You can set the size in PreCreateWindow(..) of MainFrm.cpp of your SDI.
Loot at below.
BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs)
{
if( !CFrameWnd::PreCreateWindow(cs) )
return FALSE;
// TODO: Modify the Window class or styles here by modifying
cs.cx=450;
cs.cy=600;
return TRUE;
}
|
|
|
|
|
Hi all,
can someone tell me how to create fonts or create a .ttf file for a new language on windows.
I need to know the mannual method of doing this and not to use some utility.
You can assume that I need to write an utility to create font.
modified on Thursday, August 21, 2008 6:17 AM
|
|
|
|
|
This isnt in first place a programmic topic. It is a question of the .tff file format. I think it ia a black& white raster bitmap where every charcater has its place.
Greetings from Germany
|
|
|
|
|
just FYI, TTFs are vector-based, not bitmap-based. that's how they can scale smoothly.
|
|
|
|
|
Greetings Kartenk.
I need that information to create an application. I need to display a character in my mother tongue. The character has a unicode value.
|
|
|
|
|
Hello everyone,
Today I have some free time to debug into string class itself. Here is the related sample code I debugged.
Two questions,
1. I have debugged that for small buffer (size <= 15), string will use buffer on stack, char array, and for larger buffer (>15), the space on heap is used (and destructor of string will free the space on heap), correct?
2. What is the function of the internal member variable _Bx._Buf and _Bx._Ptr? I have posted my debug results and why sometimes _Bx._Ptr is bad ptr and sometimes _Bx._Ptr has valid content.
I debugged under VS 2008.
#include <string>
using namespace std;
string foo()
{
string b;
b.append ("msdn");
b.append (".microsoft");
b.append (".com");
return b;
}
int main()
{
string s1 = foo();
return 0;
}
thanks in advance,
George
|
|
|
|
|
George_George wrote: 1. I have debugged that for small buffer (size <= 15), string will use buffer on stack, char array, and for larger buffer (>15), the space on heap is used (and destructor of string will free the space on heap), correct?
I guess only looking at the source of the string class will tell this certainty.
Personally, I'm not sure at all about this point, so i won't answer at the risk of saying a mistake.
[add] looking at the piece of code provided by CPallini, you seemed to be right here [/add]
George_George wrote: 2. What is the function of the internal member variable _Bx._Buf and _Bx._Ptr? I have posted my debug results and why sometimes _Bx._Ptr is bad ptr and sometimes _Bx._Ptr has valid content.
Again, looking at the source of the string class will ensure you about their use.
looking at the name of the attributes however, i'd say for sure that _Buf is the internal buffer of the string instance, the place which stores the characters you put within the string actually.
_Ptr may be invalid for some optimization reasons, but again here, i'm not sure at all, and stepping into the append() method code will tell you exactly how it's used and what for...
|
|
|
|
|
Thanks toxcct,
I come here to ask for some experience of guys who has debugged before.
Actually I have debugged into append, but the template functions, you know looks very confusing.
regards,
George
|
|
|
|
|
get used to it
|
|
|
|
|
Me too, now I am addicted to managed code.
regards,
George
|
|
|
|
|
George_George wrote: 1. I have debugged that for small buffer (size <= 15), string will use buffer on stack, char array, and for larger buffer (>15), the space on heap is used (and destructor of string will free the space on heap), correct?
I haven't checked that, but it appears a quite reasonable (and desiderable) behaviour.
George_George wrote: 2. What is the function of the internal member variable _Bx._Buf and _Bx._Ptr? I have posted my debug results and why sometimes _Bx._Ptr is bad ptr and sometimes _Bx.
Hint (STL source code):
union _Bxty
{
_Elem _Buf[_BUF_SIZE];
_Elem *_Ptr;
} _Bx;
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks CPallini,
1.
So, your answer to my question 1 is _Buf is used to hold small sized content, and _Ptr is used to hold larger sizes content. Small sized content is on stack and larger sized content is on heap, correct?
2.
What is your answer to my original question item 2? I think because when the content is small, only _Buf is used and _Ptr is empty, so _Ptr is bad ptr? Correct understanding?
regards,
George
|
|
|
|
|
George_George wrote: 1.
So, your answer to my question 1 is _Buf is used to hold small sized content, and _Ptr is used to hold larger sizes content. Small sized content is on stack and larger sized content is on heap, correct?
Yes (and, as I stated that is a clever and desiderable behaviour).
George_George wrote: 2.
What is your answer to my original question item 2? I think because when the content is small, only _Buf is used and _Ptr is empty, so _Ptr is bad ptr? Correct understanding?
It is a bit more subtle: since _Buf & _Ptr share the same (at least sizeof(_Ptr) ) memory locations, because both of them belongs to a union , hence _Prt is a bad pointer when
(1) The context requires _Buf usage (i.e. short string).
(2) the initial characters of the string (for instance {_Buf[0], _Buf[1], _Buf[2], _Buf[3]} for ANSI strings), interpreted as a pointer, give an invalid address.
For instance the following code
union Foo
{
char a[4];
char *p;
};
void main()
{
Foo f;
f.a[0]='m';
f.a[1]='s';
f.a[2]='d';
f.a[3]='n';
}
(as side effect) assigns 0x6e64736d , i.e. an invalid address to f.p .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|