Email Password Remember me?  Lost your password?

• Download source files - 15.3 Kb
• Download demo project - 5.83 Kb

Introduction

• MS Spy++ Style Window Finder

It also incorporates the screen capture routine presented by Joseph M. Newcomer in his CodeProject article

• Screen Capture to the Clipboard

The demo app is a Sys Tray utility that activates a context menu when doubled-clicked. Using the demo app, you are able to capture any window or control anywhere on the screen and save the screen-captured bitmap into the clipboard. After that, you'll be able to paste the bitmap from the clipboard onto any bitmap editing tool of your choice.

Although my main intention is to give a demonstration of one possible use of the Window Finder utility, such a screen capture utility is pretty useful all on its own. Although you can always use the "PrintScreen" button or the "Alt+PrintScreen" buttons, this utility allows you to precisely select windows and controls. Thus saving you the trouble of having to perform further bitmap area selection and cutting and pasting.

Usage

• Start the demo app and the Window Snapshot icon will appear in the System Tray area :

  

• Right-click on the icon and a context menu will appear. There will be 3 menu items :
  • Take A Snapshot - this option will invoke the "Search Window" dialog box which will allow you to select a window or control to take a screenshot of.
  • About - displays an about message box.
  • Shutdown - shuts down the entire Sys Tray app. [Note that if the Search Window Dialog Box is already running, right-mouse-clicking on the icon will not bring up the context menu.]
• You can also double-click on the icon to directly invoke the Search Window Dialog box. If the dialog box is already running, it is brought to the foreground.
• Once a window is selected, its information will be displayed in the Search Window Dialog Box and once you click on the "OK" button, a screenshot of the selected window or control will be taken and saved into the system clipboard.
• Thereafter, use your favourite bitmap editing tool to further edit or save the bitmap.

Summary Of How It Works

• From Standard Window App to System Tray App. This requires :
  • Adding a Sys Tray icon.
  • Hiding the main window of the app.
  • Defining a custom Window message for processing Sys Tray activities.
  • Defining a context menu to be activated when the user right-clicks on the Sys Tray icon.
  • Defining handlers for the context menu items.
• Screen Capturing the selected Window/Control.
  • After a window has been selected and the user selects the "OK" button of the Search Window Dialog Box, we proceed to take a snapshot of the window or control.
  • A slightly modified version of Joseph Newcomer's toClipboard() routine is used to perform the screen capture.
  • I made the modifications to Joseph's toClipboard() routine to handle some possible resource leakage detected by Numega's Bounds Checker while I was doing debugging.
• I have informed Joseph of the possible leakage and Joseph has kindly informed me he will look into this.

Detailed Explanation Of How It Works

  // Enhancement to WindowFinder - main window will not have 

  // WS_VISIBLE style.

  dwStyle = WS_OVERLAPPEDWINDOW;  

  // Create the main window.

  g_hwndMainWnd = CreateWindow
  (
    szMainWindowClassName,     // name of window class 

    WINDOW_SNAPSHOT_MAIN_WINDOW_TITLE,  // title 

    dwStyle, // window style - normal 

    CW_USEDEFAULT, // X coordinate - let Windows decide 

    CW_USEDEFAULT, // Y coordinate - let Windows decide 

    CW_USEDEFAULT, // width - let Windows decide 

    CW_USEDEFAULT, // height - let Windows decide

    NULL,          // no parent window 

    NULL,          // no override of class menu 

    hInstance,     // handle for this instance

    NULL           // no additional arguments 

  );

  ...
  ...
  ...

  // Display the window. 

  ShowWindow(g_hwndMainWnd, SW_HIDE);  
    // Enhancement to WindowFinder - hide the main window.


  UpdateWindow(g_hwndMainWnd);

The main window will still be required to process messages for the Sys Tray icon.

I have also defined a new function InitialiseShellModules() which is called within WinMain(). This function will perform initializations for the Sys Tray icon. This function is listed below :

BOOL InitialiseShellModules()
{
  NOTIFYICONDATA nid;
  BOOL bRetTemp = FALSE;
  BOOL bRet = TRUE;

  g_hIconSysTray = (HICON)LoadImage
  (
    (HINSTANCE)g_hInst, 
      // handle of the instance that contains the image 

    (LPCTSTR)MAKEINTRESOURCE(IDI_ICON_SYS_TRAY), 
      // name or identifier of image 

    (UINT)IMAGE_ICON, // type of image 

    (int)16, // desired width 

    (int)16, // desired height 

    (UINT)0 // load flags 

  ); 

  memset (&nid, 0, sizeof(NOTIFYICONDATA));
  nid.cbSize = sizeof(NOTIFYICONDATA);
  nid.hWnd = g_hwndMainWnd;
  nid.uID = ICON_ID;
  nid.uFlags = NIF_MESSAGE | NIF_ICON | NIF_TIP;
  nid.hIcon = g_hIconSysTray;
  nid.uCallbackMessage = WM_SYS_TRAY_MESSAGE;
  strcpy (nid.szTip, WINDOW_SNAPSHOT_TOOL_TIP);
  
  bRetTemp = Shell_NotifyIcon
  (
    (DWORD)NIM_ADD, // message identifier 

    (PNOTIFYICONDATA)&nid // pointer to structure 

  ); 

  g_dwLastError = GetLastError ();

  return bRet;
}

The function contains basic sys tray initialization and startup code. The counterpart of InitialiseShellModules() is UninitialiseShellModules() which will basically unregister our icon from the System Tray.

As can be seen in InitialiseShellModules(), we have indicated that the main application window g_hwndMainWnd is to receive the WM_SYS_TRAY_MESSAGE message meant for our icon. Hence, we provide a WM_SYS_TRAY_MESSAGE message handler in MainWndProc() :

  case WM_SYS_TRAY_MESSAGE:
  {
    lRet = 0;
    bCallDefWndProc = TRUE;

    if (wParam == ICON_ID)
    {
      // Enhancement - Bio/Andrew Peace. Invoke context menu 

      // only when RIGHT-mouse click.

      if (lParam == WM_RBUTTONDOWN)
      {
        // Enhancement to Window Finder - display context menu only 

        // if we currently allow it. 

        if (g_bAllowContextMenu)
        {
          DisplayContextMenu (hwnd);
        }
      }

      // Enhancement - Bio/Andrew Peace. Invoke Search Window Dialog 

      // directly when icon is double-clicked.

      if (lParam == WM_LBUTTONDBLCLK)
      {
        // Enhancement to Window Finder - display the Search Window 

        // Dialog box immediately. If the Search Window Dialog is 

        // already alive, put it in the foreground. 

        if (g_hwndSearchDialog)
        {
          SetForegroundWindow (g_hwndSearchDialog);
        }
        else
        {
          PostMessage (hwnd, WM_START_SEARCH_WINDOW, 0, 0);
        }
      }
    }
    break;
  }

When the user right-clicks on the icon, we first check the BOOL flag g_bAllowContextMenu to see if we allow the display of the context menu. This is important because we do not want to allow the user the possibility of having two Search Window Dialogs running at the same time. The g_bAllowContextMenu flag is set to TRUE when the Search Window Dialog Box is displayed and will be set to FALSE when it is closed (see the WM_INITDIALOG and the WM_COMMAND (with wID == IDOK) message handlers in SearchWindowDialogProc() for more details).

We may, of course, opt to disable the "Take A Snapshot" menu item. This is a good idea, especially if there are any other options in the context menu not related directly to window selection. This will certainly complicate the code further but it can be done. When the user double-clicks on the sys tray icon, to directly start up the Search Window Dialog Box, we first check the global variable g_hwndSearchDialog to see if it contains any value. This g_hwndSearchDialog global variable is set to the HWND of the Search Window Dialog box when the dialog box is started up (see WM_INITDIALOG handler in SearchWindowDialogProc()) and is set to NULL when the dialog is closed (see WM_COMMAND, wID == IDOK, in SearchWindowDialogProc()).

If the Search Window Dialog Box is not running at the moment (null value in g_hwndSearchDialog), we start up the dialog by posting the WM_START_SEARCH_WINDOW message to the Main Window. If the Search Window dialog box is already running at the moment (non-null value in g_hwndSearchDialog), we bring the Search Window to the foreground immediately. This provides greater convenience for the user especially when the Search Window is hidden by another window. By bringing the Search Window dialog to the foreground when the user double-clicks the Sys Tray icon, the user can avoid minimizing windows in order to get to it.

The various handlers for the context menu items are listed below. They are part of the WM_COMMAND handler of the MainWndProc() :

  case WM_COMMAND:
  {
    WORD wNotifyCode = HIWORD(wParam); // notification code 

    WORD wID = LOWORD(wParam);         
      // item, control, or accelerator identifier 

    HWND hwndCtl = (HWND)lParam;      // handle of control 


    if (wNotifyCode == 0)
    {
      // Message is from a menu.

      // Enhancement to Window Finder - perform 

      // a window snapshot operation.

      if (wID == IDM_CONTEXT_TAKE_SNAPSHOT)
      {
        PostMessage (hwnd, WM_START_SEARCH_WINDOW, 0, 0);
      }

      if (wID == IDM_CONTEXT_ABOUT)
      {
        MessageBox (NULL, ABOUT_WINDOW_FLOATER, 
             WINDOW_SNAPSHOT_MAIN_WINDOW_TITLE, MB_OK);
      }

      if (wID == IDM_CONTEXT_SHUTDOWN)
      {
        PostMessage (hwnd, WM_CLOSE, 0, 0);
      }

      lRet = 0;
      bCallDefWndProc = FALSE;
    }
    else
    {
      bCallDefWndProc = TRUE;
    }
 
    break;
  }

Let us examine the handler for IDM_CONTEXT_TAKE_SNAPSHOT. It will post the WM_START_SEARCH_WINDOW message back to the main window which will eventually call on StartSearchWindowDialog() to start the Search Window dialog box :

  case WM_START_SEARCH_WINDOW :
  {
    lRet = 0;
    bCallDefWndProc = FALSE;

    StartSearchWindowDialog (hwnd);

    break;
  }

The Window Search Dialog Box is managed by the SearchWindowDialogProc() dialog box procedure. This has been covered in my "MS Spy++ Style Window Finder" article. Please refer to the article for more details.

The important modification to the original SearchWindowDialogProc() is the handler for the IDOK button :

  if ((wID == IDOK) && (g_hwndFoundWindow))
  {
    // Action.  

    // Important to hide the dialog and make sure it really disappears 

    // before we take the snapshot.

    ShowWindow (hwndDlg, SW_HIDE);
    Sleep(500);  // That's why we must wait for a while.

    CaptureWindowToClipboard (g_hwndFoundWindow);
  }

Here, when the user clicks on the "OK" button, and a window or control has been selected, we perform 3 important steps to capture the screenshot of the selected window/control :

• We hide the Search Window dialog box.
• We halt our application for about half a second.
• We proceed to perform the screen-capture which is encapsulated by the CaptureWindowToClipboard() function.

The reasons for taking the 3 steps are explained next. In general, before one captures the screen shot of a window or control, that window or control must be entirely visible. It must not be obscured partially or entirely by another window. Please refer to the discussion thread in Joseph Newcomer's "Screen Capture to the Clipboard" article in which this is discussed.

As such, please ensure that the selected window/control is totally visible when you click on the "OK" button of the Search Window dialog box. Note that this is most evident when you are performing debugging because you will be brought to the Visual Studio IDE and the selected window may be obscured. However, anticipating that the Search Window Dialog Box itself could be obscuring the selected window/control, I have made sure that I first hide the dialog box before performing the screen capture.

Furthermore, while I was doing testing, I noticed that sometimes, even after I have commanded the dialog to hide itself, I still get an image of the dialog box on top of the selected window in the screenshot. The speed of the hiding of any window really depends on the OS itself. To get round this problem, I have added in the Sleep() API to make our application halt for just half-a-second (enough time to make sure the dialog box is really hidden) before taking the screenshot. If you find that you need more time for this, simply increase the parameter for Sleep() to a greater value.

I would also like to touch a little on the CaptureWindowToClipboard() function and the modifications that I made to Joseph's toClipboard() function.

BOOL CaptureWindowToClipboard (HWND hwndToCapture)
{
  BOOL bRet = FALSE;

  // Enhancement - Bio/Ahmed. Check first that "hwndToCapture" 

  // is a valid window.

  if((hwndToCapture) && (::IsWindow (hwndToCapture)))
  {
    bRet = TRUE;
    toClipboard_Bio((CWnd *)CWnd::FromHandle (hwndToCapture), TRUE);
  }

  return bRet;
}

I basically used the CWnd::FromHandle() method to dynamically convert the selected window to a CWnd pointer.

void toClipboard_Bio(CWnd * wnd, BOOL FullWnd)
{
  CDC *dc;
  if(FullWnd)
  { /* full window */
    dc = new CWindowDC(wnd);
    //HDC hdc = ::GetWindowDC(wnd->m_hWnd);

    //dc -> Attach(hdc);

  } /* full window */
  else
  { /* client area only */
    dc = new CClientDC(wnd);
    //HDC hdc = ::GetDC(wnd->m_hWnd);

    //dc -> Attach(hdc);

  } /* client area only */

I have created a new function toClipboard_Bio() which is essentially a copy of Joseph's toClipboard() routine albeit I changed the "dc" variable from a CDC object to a pointer to a CDC. Via polymorphism, I have later created a pointer to a CWindowDC or a CClientDC based on the FullWnd BOOL parameter. All references to "dc" have been modified in the light of the fact that "dc" is now a pointer. I have also made sure that "dc" is deleted at the end of the routine. The problem discovered with Joseph's code lies in the way that CDC objects are destroyed. Please refer to my discussion thread in Joseph's article for more details.

In Conclusion

• I would like to thank Joseph Newcomer for his Screen Capture code. I hope readers of Joseph's article will find this utility useful as well.
• I would also like to thank the many readers who have read this article and have given me very supportive comments and suggestions. Through their suggestions and bug reports, WindowSnapshot has been upgraded and made more robust. This spirit is truly what makes CodeProject a great web site for developers.
• Note that I have also submitted another article last week that demonstrates another effective use of the WindowFinder :

  • WindowFloater - A System Tray Utility To Make A Window Float To The Top.

• My best wishes to all.

Updates, Enhancements And Bug Fixes

• Monday January 14th 2002. Usability Enhancement.
  • An enhancement has been added to WindowSnapshot in response to Andrew Peace's suggestion (please refer to the discussion thread below) to directly invoke the Search Window Dialog box when the user double-clicks on the Sys Tray icon.
• I also noticed that while trying to capture a few screens, the context menu generally got in the way of fast deployment.
• The code changes are in main.cpp and WindowFinder.cpp. These are explained below.
  • Changes in main.cpp :

      case WM_SYS_TRAY_MESSAGE:
      {
        lRet = 0;
        bCallDefWndProc = TRUE;
    
        if (wParam == ICON_ID)
        {
          // Enhancement - Bio/Andrew Peace. Invoke context 
    
          // menu only when RIGHT-mouse click.
    
          if (lParam == WM_RBUTTONDOWN)
          {
            // Enhancement to Window Finder - 
    
            // display context menu only if we 
    
            // currently allow it. 
    
            if (g_bAllowContextMenu)
            {
              DisplayContextMenu (hwnd);
            }
          }
    
          // Enhancement - Bio/Andrew Peace. Invoke 
    
          // Search Window Dialog directly when icon 
    
          // is double-clicked.
    
          if (lParam == WM_LBUTTONDBLCLK)
          {
            // Enhancement to Window Finder - 
    
            // display the Search Window 
    
            // Dialog box immediately. If the Search Window 
    
            // Dialog is 
    
            // already alive, put it in the foreground. 
    
            if (g_hwndSearchDialog)
            {
              SetForegroundWindow (g_hwndSearchDialog);
            }
            else
            {
              PostMessage (hwnd, WM_START_SEARCH_WINDOW, 0, 0);
            }
          }
        }
        break;
      }
    

    A handler for WM_RBUTTONDOWN is added to process right-mouse-clicks and the context menu is displayed this way. Note that usual check is made to see if a context menu is allowed to be displayed in the first place. This depends solely on whether the Search Window Dialog is currently already running. If so, the context menu is not allowed to be invoked. In the WM_LBUTTONDBLCLK message handler, no context menu is displayed. Instead, the Search Window is either directly started up, or, if it is already running (most likely obscured behind other windows), it is set to be the foreground window.

  • Changes to WindowFinder.cpp :

      case WM_INITDIALOG :
      {
        g_hwndSearchDialog = hwndDlg; 
            // Enhancement to Window Finder - keep 
    
            // HWND of dialog in the global var 
    
            // "g_hwndSearchDialog".
    
        g_hwndFoundWindow = NULL;  
           // Enhancement to Window Finder - initialise 
    
           // g_hwndFoundWindow to NULL.
    
        g_bAllowContextMenu = FALSE;  
          // Enhancement to Window Finder - now disallow 
    
          // activation of context menu.
    
        SetForegroundWindow (hwndDlg); 
          // Enhancement - Bio/Andrew Peace. 
    
          // Because Search Window 
    
          //can now be invoked directly, we must set this dialog 
    
          //to foreground when it is first displayed.
    
        bRet = TRUE;
        break;
      }
    

    Because Search Window can now be invoked directly, we must set this dialog to be the foreground whenever it is first displayed.

• Thanks, Andrew, for your suggestion :-)
• Monday January 14th 2002. Bug Fix.
• A bug has been spotted by Ahmed Ismaiel Zakaria (please refer to discussion thread below) in the toClipboard_Bio() function which causes a crash when a user selects a top-level (main frame) window or any window which does not have any parent window (e.g. a parent-less dialog box).
• This is a good catch by Ahmed. Ahmed also gave some suggestions for resolving the bug and I've modified them a little. These are explained next.
  • Changes to function toClipboard_Bio() :

      // Enhancement - Bio/Ahmed. Call OpenClipboard() 
    
      // directly instead of getting parent to do it.
    
      // wnd->GetParent()->OpenClipboard();
    
      wnd->OpenClipboard();
    

    Instead of calling GetParent() from "wnd" and then using the parent window's CWnd pointer to call OpenClipboard() (which is the cause of the crash if "wnd" does not have any parent), I've decided to call OpenClipboard() from "wnd" directly.

  • Changes to function CaptureWindowToClipboard() :

    BOOL CaptureWindowToClipboard (HWND hwndToCapture)
    {
      BOOL bRet = FALSE;
    
      // Enhancement - Bio/Ahmed. Check first that 
    
      // "hwndToCapture" is a valid window.
    
      if((hwndToCapture) && (::IsWindow (hwndToCapture)))
      {
        bRet = TRUE;
        toClipboard_Bio((CWnd *)CWnd::FromHandle (hwndToCapture), 
          TRUE);
      }
    
      return bRet;
    }
    

    I've made more stringent checks on the parameter hwndToCapture so that only valid hwnds are passed to the toClipboard_Bio() function.

• Thanks, Ahmed, for spotting this for us :-)

You must Sign In to use this message board.

Per page 102550

FirstPrevNext

Capture Text cat_12a 8:18 19 May '07   Hi Bio, Would you please help me to capture text instead of bitmap. Thank you very much. Sign In·View Thread·PermaLink 2.00/5 Excellent Tool .Suchit 18:41 4 Feb '06   Hi Bio, This one came handy several places! Thanks for sharing it. On the other note, did you explore taking snap of "hidden" windows, that are behind some applications? I tried to - but could not succeed. Quantum Computing http://www.codeproject.com/useritems/quantumcomputing.asp Sign In·View Thread·PermaLink Re: Excellent Tool Lim Bio Liong 5:48 5 Feb '06   Hello Suchit, Thanks very much for using it As for hidden windows, I'll see if I can come up with something. Thanks, Suchit, Bio. Sign In·View Thread·PermaLink How capturing is working sajjadakhter 16:55 15 Jul '05   I need to capture a window in .net, can you give some hint how it can be done. Thanks Sign In·View Thread·PermaLink how can i get desktop window`s GUI in memory???? jags_vc 2:09 7 Mar '05   I want to capture the active desktop of one PC and using that that image i want to display that image to another PC using Socket programing.I alresdy capture the current desktop to bmp file.but now i want to transfer image(of active desktop)from within memory not creating its bmp file.So anybady can me suggest how i can get the image of current desktop to Memory so that i could easly read it and transfer it to other end terminal????? Sign In·View Thread·PermaLink How can i get the mouse pointer ? Rodrigo Vaz 20:00 7 Apr '04   In the first place i would like to congratulation you about your project and article . I'm tired to search for some code or resource example about "Mouse Pointer capture" , and i want to know if do you have some help to give me ? I'm using hooks to get the mouse events and with this hooks i can get the mouse POINT struct returned by mousehook and with this struct i was tried to use DrawIcon in the x y position but without success. If does anyone have a batter idea i will be thankful Thanks Rodrigo Vaz Sign In·View Thread·PermaLink Re: How can i get the mouse pointer ? eligetiv 12:32 9 Jan '05   HI, I am using the GDI way to capture the screen shot. but i faced the same problem as u do. first thing is the cursor is not shown and another thing is i have a transparent form which has some ink on it. that is also not showing up... so i would like to know whether u have any idea as how to do it? Sign In·View Thread·PermaLink How can i detect a global screen capture? Miguel Lopes 14:36 27 Oct '03   Hi. I have a problem that you may help me on: I need to implement a hook that is triggered each time the screen is captured. More specifically, it must be activated BEFORE the screen capture is made. Can you shed some light on this subject? Thanks in advance!!!!! Sign In·View Thread·PermaLink Re: How can i detect a global screen capture? Lim Bio Liong 21:36 1 Nov '03   Hello Miguel, Here are my comments : 1. >> I need to implement a hook that is triggered each time the screen is captured. Comments : 1.1 In my humble opinion, achieving this is difficult and clumzy. 1.2 I believe that screen capturing is a User-mode activity. There are no lower-level (e.g. Windows NT/XP/2K Native API) system calls that perform the work of screen capture. 1.3 Windows has already made available the whole range of APIs to capture the screen. 1.4 I believe that whenever the PrtScr button is pressed, a Windows application somewhere (running in User-mode) captures the screen and saves the bitmap into the clipboard. 1.5 You may install a Windows Keyboard hook (via SetWindowsHookEx() API) to monitor the PrtScr key and attempt to disable it or to clear the clipboard each time the key is pressed. But this does not prevent other apps from capturing the screen via other means (via buttons, using key combinations other than PrtScr, etc). 1.6 You may want to hook the User and GDI APIs that pertain to screen capture and disallow their use in certain circumstances. Your policies for disabling them would have to be well-thought-out. 2. >> More specifically, it must be activated BEFORE the screen capture is made. Comments : 2.1 My comments on this are related to the comments in section 1 above. 2.2 Using a keyboard hook is not foolproof. Hooking Windows APIs is possible. But your app must be well designed. I do not think you can achieve a generic solution. A solution designed for a particular client would usually be the case. Hope my comments are helpful to you, Miguel. Best Regards, Bio. Sign In·View Thread·PermaLink A small improvement I hope... jyodak1 8:26 30 Dec '02   Hi Lim, A very useful piece of code. I have one question and a small improvement that can make it easier to capture multiple windows/controls. The question is why is this not built using MFC? Is it just your preference to use straight WIN32 calls and build your own message handlers? I'm not really complaining, just wondering. If I was really upset about it I would port the code. It shouldn't take long... The improvement is to add another button below your Cancel button (I called it Copy and gave it the id IDC_BUTTONCOPY). Then the code replaces yours in the WM_COMMAND case. The result is that the image is copied exactly as you were, then the dialog is shown again and not ended. This allows multiple uses of the dialog without going back to the task bar for every one. if ((wID == IDOK) || (wID == IDCANCEL || wID == IDC_BUTTONCOPY)) { bRet = TRUE; // Enhancement to Window Finder - do some action when user clicks OK. if ((wID == IDOK || wID == IDC_BUTTONCOPY) && (g_hwndFoundWindow)) { // Action. // Important to hide the dialog and make sure it really disappears // before we take the snapshot. ShowWindow (hwndDlg, SW_HIDE); Sleep(500); // That's why we must wait for 1 second. CaptureWindowToClipboard (g_hwndFoundWindow); if (wID == IDC_BUTTONCOPY) { ShowWindow (hwndDlg, SW_SHOW); } } // Enhancement to Window Finder - now allow activation of context menu. g_bAllowContextMenu = TRUE; // Enhancement to Window Finder - set global var "g_hwndSearchDialog" to NULL. g_hwndSearchDialog = NULL; if (wID != IDC_BUTTONCOPY) { EndDialog (hwndDlg, wID); } } Sign In·View Thread·PermaLink How to capture the active window? Anonymous 0:42 14 Oct '02   How to capture the active window? Sign In·View Thread·PermaLink 1.00/5 Re: How to capture the active window? Anthony_Yio 1:22 15 Sep '03   ALT - PrintScreen Sonork 100.41263:Anthony_Yio Sign In·View Thread·PermaLink Errors from Source version. WREY 13:23 11 Aug '02   Three errors resulted from my compile and link effort of the code, using the Source version downloaded. The first 2 errors were, "Internal Compiler Error" (whatever that means), and the third error was something about being unable to continue creating a Browse file (I didn't even know that just trying to compile and link a program it would be creating a browse file, particluarly when I didn't ask for one to be created). I later disabled the creating of the browse file, which took care of that error, but the other two still remained. This was my first time doing a compile and link on the code. I had just downloaded it, and this is what I was now doing. The functions for which the remaining two errors are occurring, are specifically pointing to their names (not anywhere inside them): "StartSearchWindowDialog" and "toClipboard" I don't have much to go on, and therefore cannot give you much to figure out why. I am giving you the errors just as how I got them, "Internal Compiler Error". The question is, "What is it about your program that will make it produce such kind of errors?" I am using VC++ 6, SP5, on Win 2000 with 1 Gb of memory. (I don't know if this might have any connection with why the errors are occurring, but I am using a Dual Processor machine.) This is the first time I have ever encountered such an error. William Sign In·View Thread·PermaLink Re: Errors from Source version. WREY 16:23 11 Aug '02   Something right must be happening, because after going to Project->Settings and indicated I wasn't using MFC, I didn't want precompiled headers and not interested in generating a browse file, the compiler seemed to have taken a better liking to those revisions, producing just the following 2 errors: error LNK2001: unresolved external symbol __endthreadex error LNK2001: unresolved external symbol __beginthreadex It might not be much, but at least I have some idea about what's going on, and that's progress!! William Sign In·View Thread·PermaLink Re: Errors from Source version. WREY 17:06 11 Aug '02   After making some more changes to Project->Settings->C/C++, I finally got a clean compile and link, which then cleared the way for me to test the program. All the efforts paid off, because when I ran the program, love smiled on me, and IT WORKED!!! William Sign In·View Thread·PermaLink How to capture CMediaplayer image? Jesper S 10:15 10 Apr '02   Hi, Great program - very useful! One question though: In my program I have a CMediaplayer running and I´m not able to take a snapshot of the image played. I pause/stop the player and take a snapshot but only get the background (that is a black image with the controls of the player but not the image itself). However if I then minimize the dialog and restore it again and take a new snapshot I get the image! This is on Windows 98. On windows 2000 I get the image in the first snapshot. What seems to be the problem? Can anyone help me out? Jesper S. Denmark Sign In·View Thread·PermaLink good utility- how 2 capture menus? Joe1 2:47 15 Jan '02   thanks for your excellent utility what's i am wondering now is how i could capture the window menus: if i try to move the finder over them i am not able to snap thanks again and keep up the excellent work! Joe1 Sign In·View Thread·PermaLink Re: good utility- how 2 capture menus? Lim Bio Liong 0:16 16 Jan '02   Hello Joe1, Thanks very much for the very encouraging comments Concerning precisely capturing a window menu in its exact size : this sounds very challenging and I must say I do not have any answer to this. You can, of course, use the "PRINTSCREEN" button to do the job but you'd have to do further image cutting to isolate the menu bitmap. The one thing which I really would like to find out is whether menus are actually windows. If so, can they be isolated via an API like WindowFromPoint() ? If so, capturing the Window DC of the menu would require a different approach and the Window Finder would not be able to help us here. We would need to hook a system key like "PRINTSCREEN" and in our hook, we would capture the window of the menu while it is being displayed. We have two ways of getting the HWND of the menu : by using WindowFromPoint() or by using FindWindow(). Using WindowFromPoint is a little inconvenient unless you know the area on the screen on which the menu is currently being displayed. Using FindWindow() may be more straightforward assuming that menus have a Class Name and we know what this is. All these are just theories, Joe1. The key question to be answered is whether menus are actually windows. Research work is needed to determine this. Hope the above information will be helpful to you, Joe1. Thanks and Best Regards, Bio. Sign In·View Thread·PermaLink An error ?? Ahmed Ismaiel Zakaria 8:01 13 Jan '02   the error in the function void toClipboard_Bio(CWnd * wnd, BOOL FullWnd); where when you try to capture a window the program crashes because the assertion in the MFC code fails which is _AFXWIN_INLINE BOOL CWnd::OpenClipboard() { ASSERT(::IsWindow(m_hWnd)); return ::OpenClipboard(m_hWnd); } so i made some changes on the code i put this if :- if(FullWnd) wnd->OpenClipboard(); else wnd->GetParent()->OpenClipboard(); replacing the code wnd->GetParent()->OpenClipboard(); //fails only when loading a window as the reason above And the new function CaptureWindowToClipboard is:- BOOL CaptureWindowToClipboard (HWND hwndToCapture) { BOOL bRet = TRUE; if(::IsWindow (hwndToCapture)) { toClipboard_Bio((CWnd *)CWnd::FromHandle (hwndToCapture), TRUE); } else { toClipboard_Bio((CWnd *)CWnd::FromHandle (hwndToCapture), FALSE); } return bRet; } but it's really a good work any supplement code or question send me at ahmed_ismaiel@hotmail.com sorork ID 100.11442 Sign In·View Thread·PermaLink Re: An error ?? Lim Bio Liong 17:28 13 Jan '02   Hello Ahmed, Thankyou very much for the bug report ! Great catch ! Yes, the bug is in the getting of the parent of the "wnd" parameter passed into toClipboard_Bio(). After examining the code further I feel that we should use :       wnd->OpenClipboard(); for all cases instead of             wnd->GetParent()->OpenClipboard(); If "wnd" is a top-level (or main frame) window, then the parent of this window would be NULL and so "wnd->GetParent()" would return a NULL and cause failure when we try to OpenClipboard(). However, I feel that there really is no need to call GetParent() anyway. I'll remove this call. The check for ::IsWindow() in CaptureWindowToClipboard() is also good, Ahmed. Checks like this is always good and I'll certainly include this also. However, the call to toClipboard_Bio() with "FALSE" as second parameter is not necessary I think. The reason why there is a second parameter in toClipboard_Bio() is purely to preserve as much of the original code from Joseph Newcomer (the original coder of toClipboard()) as possible. Thanks very much, once again, Ahmed, for the very good review. Please watch for these changes as I update this article and the demo source codes within the next few days. Thanks and Best Regards, Bio. Sign In·View Thread·PermaLink Thank you Ahmed Ismaiel Zakaria 11:48 21 Jan '02   hi bio , thank you very much for putting me in the updated article ,that is really a very kind of you. i 've tested the new version and now it's working well ,really nice change I hope you made more development on the program and make a dialog and put the picture from the clipboard and support saving the picture in many formats and i can help you in this if you want Thanks and Best Regards Ahmed Sign In·View Thread·PermaLink Re: Thank you Lim Bio Liong 3:06 22 Jan '02   Hello Ahmed, You're most welcome, Ahmed. And I thank you too for spotting the important bug for us What makes this site so great is the fact that there are so many fellow developers out there who will not only share knowledge and information but will also help to notice enhancements and possible bugs. And thanks too, Ahmed, for the offer to help in picture saving in various formats. I'll keep you in mind ! Thanks and Best Regards, Bio. Sign In·View Thread·PermaLink Useful! Andrew Peace 6:51 12 Jan '02   Good article - and a useful tool too. Just a couple of things I would say; 1. A nice improvement might be to bring hte find window dialog up when the tray icon is double clicked, as well as from the menu. 2. Another point is that the tray icon doesn't work whilst hte Find Window dialog is displayed. Have you thought about using threads to get around this? Not a major point though, I guess. -- Andrew. Sign In·View Thread·PermaLink Re: Useful! Nish [BusterBoy] 9:19 12 Jan '02   Yeah, good work here I must say By the way Andrew your typing is bad, all your 'the' is typed as 'hte' Nish Sonork ID 100.9786 voidmain www.busterboy.org If you don't find me on CP, I'll be at Bob's HungOut Sign In·View Thread·PermaLink Re: Useful! Andrew Peace 13:00 12 Jan '02   Nish [BusterBoy] wrote: By the way Andrew your typing is bad, all your 'the' is typed as 'hte' Aw come one Nish, it's not os abd . Actually I'm usually quite a good typer but I obviously wasn't paying attention this morning when I made that post. By the way, I'm not typing this at home and for once can say I'm using a smaller monitor than yours, you'll be pleased to hear. Only for today and tomorrow though till I get back home to my 19" . -- Andrew. Sign In·View Thread·PermaLink 2.00/5

Last Visit: 12:21 22 Nov '09     Last Update: 12:21 22 Nov '09 12 Next »