|
how can i make CListCtrl control have flat style or CListCtrl skinable?
thank you!
|
|
|
|
|
Turn off the WS_BORDER style and/or WS_EX_CLIENTEDGE extended style until you get the look you want.
--Mike--
THERE IS NO THERE IS NO BUT THERE IS
MAGIC PIXIE DUST BUSINESS GENIE CODE PROJECT
Homepage | RightClick-Encrypt | 1ClickPicGrabber
"You have Erica on the brain" - Jon Sagara to me
|
|
|
|
|
thank you!
|
|
|
|
|
How to Highlight the selected area frame when I have selected some cells and issue the copy command,like Excel?
Kanghongyuan
|
|
|
|
|
Dear all
Can someone tell me how to use "This" point, and what "This" is ?
Thanks
|
|
|
|
|
this is a pointer to the class in which the current function is a member.
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Here are some examples of when this is used:
1. Sometimes you will see it as a function parameter. For example, registering a callback: Server::RegisterCallback( this );
2. It is used for a lot of overloaded operators:
Vector const & operator +( Vector const & b )<br />
{<br />
...<br />
return *this;<br />
}
3. When overloading operator= you must make sure that the source is not the same as the destination:
Vector const & operator =( Vector const & b )<br />
{<br />
if ( this != &b )<br />
{<br />
...<br />
}<br />
return *this;<br />
}
You will probably never see "this->" because there is never a need for it -- it is automatic.
|
|
|
|
|
I am trying to attach to a process with my debugger, but I want to specify a different debugger. I seem to recall there being a registry key that I am supposed to set. Anyone know what it is, and are there other steps I have to take?
Jon Sagara
I have no complaint with the “mentoring concept” or the marriage concept or the sex concept. But if you pay for any of those, something’s wrong.
-- John T. Reed in The real estate B.S. artist detection checklist [^]
|
|
|
|
|
Does this help?
From the "Debugging Applications" book:
Common Debugging Question
--------------------------------------------------------------------------------
How do I change the default debugger that the operating system will use when a crash occurs?
When an application crashes, Windows 2000 looks in the registry key HKEY- _LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug , and Windows 98 looks in the [AeDebug] section of WIN.INI to determine what they should call to debug the application. If no values are in the key, Windows 2000 reports the address of the crash. If an access violation caused the crash, Windows 2000 also reports the memory location that the process couldn't read or write. Windows 98 displays the standard crash dialog box, and if you click the Details button, it will list the module, address, and registers at the time of the crash.
Three possible string values can be placed in the AeDebug key or section.
Auto
Debugger
UserDebuggerHotKey
If Auto is set to 0 (zero), the operating system will generate the standard crash dialog box and enable the Cancel (Windows 2000) or Debug (Windows 98) button if you want to attach the debugger. If Auto is set to 1 (one), the debugger is automatically started. The Debugger value specifies the debugger the operating system will start on the crashed application. The only requirement for the debugger is that it supports attaching to a process. The UserDebuggerHotKey value identifies the key that will be used to break into the debugger. Refer to the section "Quick Break Keys" later in the chapter to find out how to set this value.
You can set the AeDebug key manually, but Dr. Watson (Windows 2000 only), WinDBG, and the Visual C++ debugger allow you to set it through various means. Dr. Watson and WinDBG use the -I command-line switch that will set them as the default debugger. To set the Visual C++ debugger as the debugger the operating system will call, on the Debug tab in the Options dialog box, check Just-In-Time Debugging.
If you do look at the AeDebug key, the value that's entered for Debugger looks like a string passed to the wsprintf API function: "drwtsn32 -p %ld -e %ld -g." That's exactly what it is. The -p is the process ID for the crashing process, and the -e is an event handle value that the debugger needs to signal when its debug loop gets the first thread exit debug event. Signaling the event handle tells the operating system that the debugger attached cleanly.
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
That's exactly it. Thanks!
Jon Sagara
I have no complaint with the “mentoring concept” or the marriage concept or the sex concept. But if you pay for any of those, something’s wrong.
-- John T. Reed in The real estate B.S. artist detection checklist [^]
|
|
|
|
|
Normally when I prompt the user for input I flush the buffer, and it works fine:
cout << "Enter path to input file: " << flush;
But now I'm trying to do the same thing in a class_name.cpp file and I get (notice no type between tics):
error C2679: binary '<<' : no operator defined which takes a
right-hand operand of type '' (or there is no acceptable
conversion)
In the class_name.h file I do this to inherit from fstream:
#include <fstream.h>
class class_name:public fstream
{
...
}
If I remove the flush keyword it works fine. And, kinda weird, but the endl keyword also works fine.
I do have this in class_name.cpp:
#include "class_name.h"
#include <iostream.h>
Why does flush bomb out?
Thanks.
|
|
|
|
|
Isn't flush a method rather than something you pass to the stream?
i.e.
cout << "blah";
cout.flush();
Dave
|
|
|
|
|
YES. That works. Thank you.
cout << flush; also works in most cases, but apparently your way is better.
thanks
|
|
|
|
|
Iam using CDhtmlDialog class to display the images in a dialog window.It works fine .But the problem is that while displaying images ,it displays the images with a 10 ,20 pixel offset .ie. the image is displayed with a offset of 10 pixel from the window boundary .
I think this problem is something related to the IE .If u opena image in aIE ,the iE leaves a 10 X 20 offset for diplaying a image .
How can i avoid this ???
|
|
|
|
|
I got the answer too ..
CDhtmlDialog object
Object.m_pBrowserApp->get_FullScreen((VARIANT_BOOL *)TRUE);
sorry for bothering u guys
|
|
|
|
|
Hi all --
I want to create a shared memory allocator for STL containers, similar to the design employed in a recent issue of CUG, which had an article on doing such in Linux: http://www.cuj.com/current/?topic=current
In this article, a Factory pattern is used to construct an *entire* STL container in shared memory, which is exactly what I want to do, but I suspect the solution in this article is flawed. (If anyone has read this article I'd be curious to know if you came to the same conclusion.)
The reason it's flawed is because there is a tacit assumption that the virtual memory address returned by 'shmat' (roughly, the linux equivalent of the Win32 MapViewOfFile API) is the same across diff't processes.
I actually have no idea how safe this assumption is in Linux, but I know in Windows NT 4.0 that MapViewOfFile does tend to return the same address across processes for a given requested size when the WinNT paging file is used to back the virtual memory. But NT cannot guarantee this is true; therefore I cannot use MapViewOfFile. MapViewOfFileEx, on the other hand, lets the calling process request a particular starting virtual address, but if the process has already allocated any addresses in that range the call fails and returns 0, so this is not much better than MapViewOfFile as far as I can tell.
So my question is about the predictability of MapViewOfFileEx: who has experience with this (specifying a particular area in virtual memory)? How often and under what conditions does MapViewOfFileEx fail? I'm worried that relying on it would lead to an unreliable shared memory allocator, and yet I have no idea how often in practice people actually use this. Any thoughts, guidance here?
Many thanks,
Chris
|
|
|
|
|
clm wrote:
The reason it's flawed is because there is a tacit assumption that the virtual memory address returned by 'shmat' (roughly, the linux equivalent of the Win32 MapViewOfFile API) is the same across diff't processes.
I haven't read the CUJ article (yet) but I do have some experience with Memory Mapped Files. I do know that the address you get back from MapViewOfFile() differs on W98 and WXP for example. This is important where you use MMF as a persistant store with embedded memory addresses as it means the file isn't portable. I can't comment on requests for a specific address using MapViewOfFileEx() other than to say that again this won't work with the same address across W98 and WXP.
Why do you need the same address in different processes anyway?
For a simple example of my use of MMF see my mods to pugxml http://www.codeproject.com/soap/pugxml.asp[^]
If you want some references to MMF articles etc. let me know.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Hi Neville -
Thanks for your thoughts here -- your experience w/MMF is exactly what I wanted to hear (I read the specs on the relevant API calls from books and MSDN). It sounds like MapViewOfFile is out of the question for what I want to do, as I suspected.
Here is the reason why (ideally) the same address would be returned by MapViewOfFile in different processes:
Consider constructing a list<int> object in shared memory. The process that populates the (doubly linked) list creates nodes with pointers embedded in each node(*). These pointers are valid only in the process which created the list if the MVOF() return value differs between processes. So when a second process attaches to shared memory and accesses the linked list, it will immediately GPF (if we're lucky).
So I need the base address to be the same in different processes if I follow the type of solution in that CUJ article. In this implementation, the entire container is constructed in shared memory using a custom allocator, which manages a free list ('Chunks').
Of course, a workaround would be to add a level of indirection in the STL container implementations, so that offsets from a base pointer, not pointers, are cached. (MapViewOfFile return value is the base).
I'd be interested in any references to MMF articles you know -- feel free to email me, thank you very much.
-- Chris
(*) True for the VC6.0 and 7.0 STL implementations, at least.
|
|
|
|
|
|
Neville, thank you!! The links were great -- just the info I was looking for -- and the advice on using autopointers (storing offsets while supplying pointer semantics) was spot on.
This is definitely something I have a production need for, not an academic exercise. The CUJ article is in Apr 2003, unfortunately it apparently is not available on their website (I will email you about this).
Cheers,
Chris
|
|
|
|
|
Here is the example code.
class outer
{
class inner
{
outer* p_outer;
};
};
now in the constructor of inner class i need the pointer of outer.
Any idea on how this could be done?
|
|
|
|
|
outer::outer : inner (this)
{
}
That should work but there are some restrictions. Don't try to do anything serious with p_outer in inner's constructor. The instance of outer hasn't been fully constructed yet.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
It seems to give me pointer to inner, not pointer to outer class.
|
|
|
|
|
No, you are supplying the "this" pointer to inner's constructor from outer's constructor. Thus "this" points to outer.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi!
Following situation:
I've a very huge class with some arrays in it. Every user input I call the following function:
CMyClass GetByValue()
{
return m_Class;
}
Then:
void OnUserInput(...)
{
CMyDoc pDoc = GetDocument();
CMyClass cClass = pDoc->GetByValue();
//Some operations with cClass...
[...]
}
After a period of time the app slows down (because m_Class gets very big -> arrays inside it are filled)...
Is there a possibility to fast-copy a class? Or to fast-copy CArrays?
I can't use pointers cause' I need a COPY of m_Class -> the original m_Class should not be modified...
Build a system that even a fool can use, and only a fool will use it.
|
|
|
|