|
*print screen*
-->Open MS Paint
*paste*
*crop* (if necessary) [aside] You can use alt + print screen to capture the current window. [/aside]
File-->save as:
Select jpg format if you don't have a compression utility like win zip. Or you can choose bmp and zip it afterwards.
*attach file to e-mail*
*send*
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
Also you can press Alt+Print Screen to capture "Active Window".
use paint to paste bitmap!
A. Riazi
|
|
|
|
|
A. Riazi wrote:
Also you can press Alt+Print Screen to capture "Active Window".
He said that!
Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C#, ASP.NET and C++!
|
|
|
|
|
Here's my suggestion: read the data directly from the clipboard. The format of the data in the clipboard is Device Independant Bitmap (CF_DIB).
There's a MFC sample that retrieve a DIB from the clipboard. Search for DIBLOOK in MSDN.
Once you have the DIB you can save it in an other format. We used Stringray SECJpeg class a few years ago but you can surely find great code for that on the net (if not on this site...).
Good luck.
|
|
|
|
|
I have a class derived from CListCtrl, and I want it send a customized message to its parent window(which is derived from CDialog) when in need. So I defined a message ID, say, "#define WM_SOMETHING WM_APP + 100" in my project and handle this message by the following way:
void CMyListCtrl::OnSomething
{
CWnd* pParent = GetParent();
if (pParent != NULL)
pParent->PostMessage(WM_SOMETHING, 0, 0);
}
afx_msg void OnSomethingHappened();
BEGIN_MESSAGE_MAP(CMyDlg, CDialog)
ON_MESSAGE(WM_SOMETHING, OnSomethingHappened)
END_MESSAGE_MAP()
void CMyDlg::OnSomethingHappened()
{
}
Now, in debug mode it works great, but in release mode it crashes. If I remove the "PostMessage..." code from implementation of CMyListCtrl, it will not crash so the problem must be there... What am I doing wrong? Thank you.
|
|
|
|
|
Your message handler function has to have the form
LRESULT CMyWnd::OnMyMessage(WPARAM WParam, LPARAM LParam)<br />
{<br />
return (LRESULT)0;<br />
}
If your app crashes in release mode the cause should be your wrong function declaration.
|
|
|
|
|
|
As a note, take a look at RegisterWindowMessage() as any WM_SOMETHING message defined using
#define WM_SOMETHING WM_USER + x
can be problematic as the message number may be in use my one of the new common controls. WHich can give possible unpredictable behaviour to your app at a later time (especially when their implementation changes)
Roger Allen
Sonork 100.10016
WHats brown and sticky?
A stick or some smelly stuff!
|
|
|
|
|
I think it doesn't matter as long as your messages are only to be used in your application, not system-wide. As MSDN says:
WM_APP through 0xBFFF: Messages available for use by applications.
Beside that fact I think in our case RegisterWindowMessage() has not been used, as in that case we'd to take on_registered_message instead of on_message.
|
|
|
|
|
did you try ::SendMessage?
A. Riazi
|
|
|
|
|
How can I get the text to a CString from a list box
with out select anything?
\Larsson
|
|
|
|
|
I think CListBox::GetText should work.
|
|
|
|
|
Well Sorry!,
I don't get the text from the Listbox.
And if i do how can a get al that is listed in the listbox?
|
|
|
|
|
Here's an example how to get all items' text:
CListBox lb;
...
CString str;
int n;
for ( int i = 0; i < lb.GetCount(); i++ )
{
n = lb.GetTextLen( i );
lb.GetText( i, str.GetBuffer(n) );
str.ReleaseBuffer();
}
or
CListBox lb;
...
CString str;
for ( int i = 0; i < lb.GetCount(); i++ )
{
lb.GetText( i, str );
}
should work, too. In both cases str holds the current item's text.
|
|
|
|
|
Thank's you are a star.
\Larsson
|
|
|
|
|
Hi,
in the past, when our application were pure C based, we had our own malloc and free routines. These were called by simply re-#defining malloc and free as C-macro's and 'route' them to our own PrivateMalloc and PrivateFree routines.
Now, in C++, we want of course to reuse our memory manager (which has some peculiar advantages for us), however, we see some problems:
- In our old software, the memory pools were initialized when the application started up (as first action). Now, in C++, new can already be executed before the main is actually called (e.g. in the constructor of a global variable). However, we think we can solve this by performing the initialisation of the memory pools in the first call to 'new'.
- In our old software, leaked memory was reported at the end. Since global variables' destructors are executed after the application has finished, we cannot report memory leaks at the end of the application, since the list will always contain memory that still needs to be deleted by the global variables' destructors.
- MFC seems to have their own new and delete implementation. We aren't sure that MFC doesn't rely on some specific part of their implementation. Can we simply ignore the MFC new/delete and use our own implementation?
I don't know how other memory managers solve that problem.
Maybe anyone of you have already written their own new/delete implementation; then, how have you done that? And did you encounter any problems with MFC?
Thanks in advance.
Patje.
Enjoy life, this is not a rehearsal !!!
My Articles:
- Implementing a Subject/Observer pattern with templates
|
|
|
|
|
1. The approach you are suggesting is just right.
2. Use atexit .
3. In release mode, MFC uses the same new as everybody. In debug mode, new is a macro that resolves to an overload of new specifying the file and the line where the call occurs. Don't know how this can be ridden of.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks for your answer Joaquin.
When I saw "atexit", I thought "yes, that's it". Unfortunately, my colleague saw the following in the MSDN documentation:
Using atexit
With theatexit function, you can specify an exit-processing function that executes prior to program termination. No global static objects initialized prior to the call to atexit are destroyed prior to execution of the exit-processing function.
As I understand it, it seems like the global variables are only destroyed after the atexit execution. So this doesn't seem to solve my problem.
I verified this with the following test program:
<br />
#include <stdlib.h><br />
#include <iostream><br />
<br />
class MyClass<br />
{<br />
public:<br />
MyClass() {printf ("Constructor\n");}<br />
~MyClass() {printf ("Destructor\n");}<br />
};<br />
<br />
MyClass myVariable;<br />
<br />
void __cdecl AtExitFunction (void)<br />
{<br />
printf ("AtExit\n");<br />
}<br />
<br />
void main ()<br />
{<br />
atexit (AtExitFunction);<br />
}<br />
(I had to use printf, because std::cout wasn't available anymore in my destructor).
And indeed, the following is printed:
Constructor
AtExit
Destructor
Other suggestion???
Enjoy life, this is not a rehearsal !!!
My Articles:
- Implementing a Subject/Observer pattern with templates
|
|
|
|
|
Well, the following technique has some defficiencies, but it can serve: assume your new override is defined in say "mynew.h" : then, as every .cpp using the overriden new has to include implicitly or explicitly "mynew.h" , you can take advantage of this by forcing the construction of a "sentinel" object which, under normal conditions, is constructed before anything else:
class leak_sentinel
{
static unsigned& count(){static unsigned count_=0;return count_;}
public:
leak_sentinel(){++count();}
~leak_sentinel()
{
if(--count()==0){
}
}
};
static leak_sentinel lks;
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I posted a similar solution below, but I like your idea of a count function much better. You learn something new every day.
By the way, your count function doesn't need to be static, as far as I can tell.
Regards,
Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
|
|
|
|
|
By the way, your count function doesn't need to be static, as far as I can tell.
You're right. It's just a matter of style: count is static as there's no need for it not to be.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
count is static as there's no need for it not to be.
Yes, this is actually the same approach I usually take. If a function can be static -- it doesn't access any non-static members -- then it should be static. This allows it to be used with or without an instance of the class.
The only conflict I have with this approach is that it makes little sense when the function is private or protected. At that point it's like, "Why bother typing the static keyword when it's just an internal function? And if I ever decide to let it access non-static members, then I have to go and remove the static from it." So... I'm not convinced one way or the other when it comes to non-public functions of this type.
Regards,
Alvaro
All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain
|
|
|
|
|
If you have implemented PrivateMalloc and PrivateFree, implementing new for your classes is a matter of overwriting new for each of them, or casting the memory in case of build-ins. I am just curios what does make your memory allocation superior to standard Windows algorithms? What is it you are gaining with custom memory management?
|
|
|
|
|
I don't want to add a new and delete to every class (although we could do this with a simple define and inline new/delete methods).
Our memory allocator (written about 12 years ago) is maybe not as advanced as some commercial memory allocators, but it does the following:
- handling memory pools in discrete sizes to prevent memory fragmentation
- showing memory leaks at the end of the application
- showing the stack of the malloc-location of leaks
- detecting memory overwrites
Especially the last 3 things are interesting, because we have the most interesting functionality of e.g. Rational Purify, but without the huge overhead (in cpu-time and in cost) of it.
Thanks for your answer anyway.
Enjoy life, this is not a rehearsal !!!
My Articles:
- Implementing a Subject/Observer pattern with templates
|
|
|
|
|
this is pretty much what MFC does in debug. You can try to adapt their approach.
1. Overload global new operator with some custom parameter
2. redefine new (see how MFC does it "#define DEBUG_NEW new(THIS_FILE, __LINE__)") to be redirected to your new
do not forget array new()[]. do the same for delete.
P.S. I would question the performance lose in your approach, but I guess it is worth it for you.
|
|
|
|