|
If you really require a window handle you shouldn't implement your control as a windowless control
If you simply want your control to be redrawn, then have a look at this method your control inherited
<br />
inline HRESULT CComControlBase::FireViewChange()<br />
{<br />
if (m_bInPlaceActive)<br />
{<br />
if (m_hWndCD != NULL)<br />
::InvalidateRect(m_hWndCD, NULL, TRUE);
else if (m_bWndLess && m_spInPlaceSite != NULL)<br />
m_spInPlaceSite->InvalidateRect(NULL, TRUE);
}<br />
else
SendOnViewChange(DVASPECT_CONTENT);<br />
return S_OK;<br />
}<br />
|
|
|
|
|
Hi all, can anyone help with this...
I have allready made my own owner draw menu (CCommandBar) however, i cant create owner draw CReBarCtrl , and so, the menu bar get to be the default.
Is something missing, but i cant find what it is.
Lets look at some code:
if i declare this in mainfrm.h:
CReBarCtrl m_Bar;
and then in CMainFrame::OnCreate
<br />
CRect rc( 0,0,100,100);<br />
m_Bar.Create( m_hWnd,rc, L"WebRebar", WS_CHILD|WS_VISIBLE|WS_CLIPCHILDREN|CCS_TOP | RBS_BANDBORDERS | CCS_NODIVIDER ,0 );<br />
<br />
HWND hWndMenu = m_Menu.Create(m_hWnd, rcDefault, NULL, ATL_SIMPLE_CMDBAR_PANE_STYLE);<br />
m_Menu.AttachMenu(GetMenu());<br />
m_Menu.LoadImages(IDR_MAINFRAME);<br />
SetMenu(NULL);<br />
<br />
m_Bar.m_hWnd,rc,NULL,CCS_NODIVIDER|CCS_NOPARENTALIGN|CCS_NORESIZE|WS_CHILD | TBSTYLE_FLAT | TBSTYLE_TRANSPARENT | TBSTYLE_TOOLTIPS );<br />
<br />
AddSimpleReBarBandCtrl(m_Bar.m_hWnd,hWndMenu);<br />
Every thing works, execpt i whant to use a owner drae rebar so:
I change: CReBarCtrl m_Bar; to CMyReBarCtrl m_Bar;
and here is the problem, i cant create a CMyReBarCtrl that works.
one of the implementation that i have tryed was
<br />
class CMyReBarCtrl: public CWindowImpl<CMyReBarCtrl, CReBarCtrl>,<br />
public CCustomDraw<CMyReBarCtrl> <br />
{<br />
public:<br />
<br />
BEGIN_MSG_MAP(CMyReBarCtrl) <br />
CHAIN_MSG_MAP(CCustomDraw<CMyReBarCtrl> )<br />
END_MSG_MAP()<br />
<br />
.<br />
.<br />
.<br />
}<br />
But it dosent work. Something is missing on my WTL knowledge.
Do anyone have any ideia of what is missing?
Thanks
-- modified at 12:22 Saturday 26th August, 2006
|
|
|
|
|
You meant custom drawn rebar correct?
Your rebar message map should look like this
<br />
BEGIN_MSG_MAP(CMyReBarCtrl) <br />
CHAIN_MSG_MAP_ALT(CCustomDraw<CMyReBarCtrl>, 1)<br />
DEFAULT_REFLECTION_HANDLER()<br />
END_MSG_MAP()<br />
Make sure you have REFLECT_NOTIFICATIONS() in your CMainFrame message map.
|
|
|
|
|
It would be interesting if someone write a article about how to custom/owner draw ReBar in WTL.
|
|
|
|
|
I've read enough comments to users (including myself) from others telling them to use STL containers in favor of MFC containers so I decided I would give it a try on my next review of my encoding classes. Well, I'm there and bought as many books I could find with chapters on STL and did some googling but most of the documentation fails to point me in the right direction in my search to replace certain functionality found in CByteArray.
It may be there but I must admit I'm a little overwhelmed at this point so I apologize for the post.
My question:
I know in advance the approx. initial size needed for the container and reasonable "Grow by" values and would like to set these like CByteArray::SetSize allows. The procedures I'm trying to revamp are for encoding/decoding Base64, Ascii85, etc... so I can't afford for numerous allocation requests. How do I set the initial size and grow by values for vector? Is this too much to bite off for an STL newbee trying to learn STL and fitting it into their production schedule somehow without getting into a lot of trouble?
-- modified at 10:41 Friday 25th August, 2006
Scratch the first question about initial size. Bjarne Stroustrup explicitly mentions how to do it in his book. I'm just missing this stuff first time aroound because I'm not at all fluent in the template arena. The Growby question is still active though.
Thanks
|
|
|
|
|
bob16972 wrote: How do I set the initial size and grow by values for vector
Initial size can be set using the resize method, although the reserve method is also useful - it allows you to say 'I want the vector to allocate storage for at least n elements - but I don't need to use it just yet'. You need to understand the difference between size (the number of elements a container contains) and capacity (the number of elements it has storage for) - that's quite an important thing.
So, for example, the following allocates space for at least three elements, and you can push_back three times after that knowing that no more allocations will be performed:
std::vector<int> vec;
vec.reserve(3);
vec.push_back(1);
vec.push_back(2);
vec.push_back(3);
You might also want to investigate std::deque - this allocates storage as a linked list of blocks, meaning that new allocations don't require relocation of existing elements.
As for GrowBy - you're out of luck there - I believe that most STL implementations tend to double the size of a vector on reallocation - but I 'm quite likely to be wrong! (And, in fact, on checking with VC7.1, I am! It allocates an extra 50% on each reallocation:
#include <iostream>
#include <vector>
int main(int, char**)
{
std::vector<int> a;
size_t cap = a.capacity();
for(int i =0;i<100000000;++i)
{
a.push_back(i);
if (cap != a.capacity())
{
cap = a.capacity();
std::cout << "Reallocation! -> " << cap << " elements\n";
}
}
}
gives
Reallocation! -> 1 elements
Reallocation! -> 2 elements
Reallocation! -> 3 elements
Reallocation! -> 4 elements
Reallocation! -> 6 elements
Reallocation! -> 9 elements
Reallocation! -> 13 elements
Reallocation! -> 19 elements
Reallocation! -> 28 elements
Reallocation! -> 42 elements
Reallocation! -> 63 elements
Reallocation! -> 94 elements
Reallocation! -> 141 elements
Reallocation! -> 211 elements
Reallocation! -> 316 elements
Reallocation! -> 474 elements
Reallocation! -> 711 elements
Reallocation! -> 1066 elements
Reallocation! -> 1599 elements
Reallocation! -> 2398 elements
Reallocation! -> 3597 elements
Reallocation! -> 5395 elements
Reallocation! -> 8092 elements
Reallocation! -> 12138 elements
Reallocation! -> 18207 elements
Reallocation! -> 27310 elements
Reallocation! -> 40965 elements
Reallocation! -> 61447 elements
Reallocation! -> 92170 elements
Reallocation! -> 138255 elements
Reallocation! -> 207382 elements
Reallocation! -> 311073 elements
Reallocation! -> 466609 elements
Reallocation! -> 699913 elements
Reallocation! -> 1049869 elements
Reallocation! -> 1574803 elements
Reallocation! -> 2362204 elements
Reallocation! -> 3543306 elements
Reallocation! -> 5314959 elements
Reallocation! -> 7972438 elements
Reallocation! -> 11958657 elements
Reallocation! -> 17937985 elements
Reallocation! -> 26906977 elements
Reallocation! -> 40360465 elements
Reallocation! -> 60540697 elements
Reallocation! -> 90811045 elements
Reallocation! -> 136216567 elements
In your case, I'd allocate your approximate initial size. If it is a reasonably good approximation, then an extra 50% should be sufficient for any overflow?
|
|
|
|
|
Stuart Dootson wrote: If it is a reasonably good approximation, then an extra 50% should be sufficient for any overflow?
Based on what I'm doing, I believe that would be correct. My main concern was that it allocated small amounts as needed if I was to surpass the reserved size.
Thank you very much for your help.
|
|
|
|
|
Stuart Dootson wrote: You might also want to investigate std::deque - this allocates storage as a linked list of blocks, meaning that new allocations don't require relocation of existing elements.
A deque is not a linked list. It is a specialized array that allows for quick insertion at both the front and back of the array. All the memory for a deque is contiguous, just as it is for a vector.
Stuart Dootson wrote: As for GrowBy - you're out of luck there
Not really. If you really want to customize how memory allocation is done for a given STL container, you just need to write your own allocator and pass it in as the second template parameter. This is generally not needed since the default allocator is sufficient for almost all cases, though.
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
|
|
|
|
|
Zac Howland wrote: All the memory for a deque is contiguous
Hmmm - not in my copy of VS 2003 (or GCC 3.4.5) - see this[^] and try the program below...
#include <deque>
#include <iostream>
int main(int, char**)
{
std::deque<char> x;
x.resize(10);
if (&x.back()-&x.front() == std::distance(x.begin(), x.end())-1)
{
std::cout << "x is contiguous\n";
}
else
{
std::cout << "x is not contiguous\n";
}
x.resize(1e6);
if (&x.back()-&x.front() == std::distance(x.begin(), x.end())-1)
{
std::cout << "x is contiguous\n";
}
else
{
std::cout << "x is not contiguous\n";
}
}
outputs
x with 10 elements is contiguous
x with 1000000 elements is not contiguous
|
|
|
|
|
I should have rephrased that. All the memory for each chunk in a deque is contiguous. That is, it allocates a fixed size chunk, when it gets filled, it allocates another fixed size chunk. My point was that it isn't a linked-list; its closer to being a map.
MSDN
SGI's Implementation
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
|
|
|
|
|
Sounds more like a linked list of arrays to me than a map.
--
Mit viel Oktan und frei von Blei, eine Kraftstoff wie Benziiiiiiin!
|
|
|
|
|
Does anyone know how to use WTL's CDoubleBufferImpl? Any article about it?
BTW: What's the meaning of "Double Buffer" within "CDoubleBufferImpl"?
|
|
|
|
|
shaohao wrote: CDoubleBufferImpl
Google finds this[^]?
|
|
|
|
|
The WM_PAINT handler sets up a memory DC and calls the derived class's DoPaint() method. That way, all your own window classes don't have to have the boilerplate double-buffering code (create a mem DC, paint to it, blit to the screen when done).
--Mike--
Visual C++ MVP
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
|
|
|
|
|
All,
I am working on ATL COM DLL and I am writing a DLL which exposes few interfaces to the application. These interfces can be called either from the VBScript or C++ routine. Any rules which i need to follow especially for having a parameter[[IN], [OUT]. As every one knows that VBScript has data type limitations and we can't pass all the parameters as like in normal. For example the IN and OUT parameter will be used to send and receive values from the interfce and should always be having a VARIANT* data type.
For example:
1. STDMETHODIMP CXX::FUNC_XX( BYTE bnl,BYTE bCurrCl,VARIANT* vSData,BOOL boFlag, SHORT *pRetVal)
2. STDMETHODIMP CXXX::FUNC1_XXX(VARIANT* vReconfig,SHORT *pRetVal)
Please let me know if any one is having suggestions or sample ATL COM DLL which can be called from VBScript.
Thanks,
AKS
|
|
|
|
|
Hi
When I started C++ I used MFC. I found CString a doddle to use sadly it turned out to be not exactly the finest of string implementations.
Has this been resolved in the WTL or should I stick with the STL string or lower level self made implementations?
Thanks
Tom
|
|
|
|
|
What versions of ATL, WTL and MFC are you using? If it's the ATL+MFC that came with VS.NET, then WTL uses the ATL CString...which is the same as the MFC one...which is a *complete* rewrite compared to the previous version of MFC.
Otherwise, I think the CString that was in WTL was much the same as the precious MFC one.
Also - what issues did you have with the MFC CString? Not that I've used it that much, I'm just interested
|
|
|
|
|
TClarke wrote: When I started C++ I used MFC. I found CString a doddle to use sadly it turned out to be not exactly the finest of string implementations.
I assume you are referring to how it allocates memory, since other than that, it actually offers many features that even the STL string class doesn't give.
TClarke wrote: Has this been resolved in the WTL or should I stick with the STL string or lower level self made implementations?
The answer to this question largely depends on what you are doing. If you are trying to write portable code, I would use std::string. If you are writing Windows-only code and have need for doing certain kinds of string operations, CString is probably the way you want to go.
The newest versions of WTL/ATL/MFC all use the same implementation of CString. Older versions were slightly different for MFC than the other toolkits.
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
|
|
|
|
|
|
Firstly, thank you to all of you for your respones
I'm using VS.NET creating code only to be used on Windows.
It's encouraging to hear that CString no longer has the reputation it did whilst in it's VC6 incarnation. The issue that alarmed me was that it was considered inefficient and slow, a heavy weight implementation included to bridge the gap until the STL string was completed. though I never noticed any cost to my programs in terms of speed or size.
"Also - what issues did you have with the MFC CString? Not that I've used it that much, I'm just interested"
My main issue is more with the STL implementaion as CString has never been any trouble to use. Why the STL string does not have an implemmentation of CString::Find, or CString::Format and all those Windows crucial overloads that makes CString a breeze to use I don't know but it's always put me off
Thanks
Tom
|
|
|
|
|
Hi
Does any know of a reason for not utilizing the WTL library when writing ActiveX controls in ATL?
Thanks
Tom
|
|
|
|
|
If you are doing windowless controls, then WTL is pretty much useless. If not, then WTL will serve you well.
--
Not based on the Novel by James Fenimore Cooper
|
|
|
|
|
Thanks
|
|
|
|
|
Hi,
I have an array A[10][2].
The first column of the array consists of marks and the second consists of student code number.
I want to sort the array based on the first column.
How do I use stl::sort() to achieve this?
Cutebug
|
|
|
|
|
You can't - arrays aren't assignable objects (i.e. you can't do x = y; where x and y are of type int[2] ), which is a requirement of any of the mutating algorithms.
I'd suggest you use records instead (oh, and std::vector s for storage rather than arrays):
#include <algorithm>
#include <vector>
struct Mark
{
int mark;
int studentCode;
};
bool operator<(Mark const& left, Mark const& right) { return left.mark < right.mark; }
int main(int, char**)
{
std::vector<Mark> marks;
std::sort(marks.begin(), marks.end());
}
Try to forget arrays ever existed...
|
|
|
|