Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
B

bjorn_ht

@bjorn_ht
About
Posts
12
Topics
0
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • OnTimer function is killed automatically when the dialog is closed
    B bjorn_ht

    I have not observed similar behavior so I'm afraid I can't help with that. Also please note that the number 42 as second parameter to SetTimer in my example was chosen randomly. Probably, it would be more correct in your context to use the value 0.

    C / C++ / MFC c++ help question

  • OnTimer function is killed automatically when the dialog is closed
    B bjorn_ht

    This is not MFC as such. SetTimer and KillTimer Windows system functions documented by Microsoft. http://msdn.microsoft.com/library/default.aspx[^] There are many good books and online resources on the subject of C++ programming, Windows system programming and MFC. I suggest you try searching the net for recommendations and book reviews.

    C / C++ / MFC c++ help question

  • OnTimer function is killed automatically when the dialog is closed
    B bjorn_ht

    You just call ::KillTimer(0, timerId); where timerId is the timer id value you got back from ::SetTimer.

    C / C++ / MFC c++ help question

  • OnTimer function is killed automatically when the dialog is closed
    B bjorn_ht

    I wrote that example for VS 2008, looks like the callback signature has changed a little since VS6. Try to change it to

    void __stdcall myOnTimer(HWND hwnd, unsigned int uMsg, unsigned int idEvent, DWORD tickCount)
    {
    // ...
    }

    as the error message suggests. If you have an MSDN library with your VS then you should be able to find the correct callback function signature there. Maybe even an example.

    C / C++ / MFC c++ help question

  • OnTimer function is killed automatically when the dialog is closed
    B bjorn_ht

    Create a console app and put this code in to see how it works, then you can adapt "myOnTimer" and the call to ::SetTimer to your code.

    #include <windows.h>
    #include <iostream>

    void CALLBACK myOnTimer(HWND hwnd, UINT uMsg, UINT_PTR idEvent, DWORD tickCount)
    {
    std::cout << "Timer. id = " << idEvent << ", tick = " << tickCount << std::endl;
    }

    int main(int argc, char * argv[])
    {
    MSG msg;

    UINT_PTR timerId = ::SetTimer(0, 42, 1000, myOnTimer);

    std::cout << "Timer set, id = " << timerId << std::endl;

    // This is done by MFC in your application but needed for the example.
    while(GetMessage(&msg, 0, 0, 0))
    {
    TranslateMessage(&msg);
    DispatchMessage(&msg);
    }
    return 0;
    }

    C / C++ / MFC c++ help question

  • OnTimer function is killed automatically when the dialog is closed
    B bjorn_ht

    I assume you talk about MFC and CWnd::OnTimer()? If so, what you describe is how I would expect it to work. That function and CWnd::SetTimer is a thin layer on the Win API ::SetTimer function and WM_TIMER message, where ::SetTimer is called with CWnd::m_hWnd as first arg. If you want the timer to continue after the window is destroyed, why don't you just call ::SetTimer directly with a NULL hWnd and a TIMERPROC? That way your timer will run as long as the thread runs or until you destroy it with a call to ::KilllTimer.

    C / C++ / MFC c++ help question

  • NMAKE can't find include file in subfolder -- SOLVED
    B bjorn_ht

    1. Oh absolutely, 2. you were right, though.

    C / C++ / MFC csharp visual-studio algorithms help question

  • NMAKE can't find include file in subfolder -- SOLVED
    B bjorn_ht

    1. Yes that could be the intention, but the compiler would look there in any case, wouldn't it? 2. So then we know it took me more than 36 minutes to type in that comment. No wonder I'm not a regular...

    C / C++ / MFC csharp visual-studio algorithms help question

  • NMAKE can't find include file in subfolder -- SOLVED
    B bjorn_ht

    Maybe it's a copy/paste bug but that command line doesn't look right to me. 1. The second include is given with option "-I.", that dot doesn't belong there. 2. The rest of the include paths are given without -I arg so the compiler probably won't know what to do with those.

    C / C++ / MFC csharp visual-studio algorithms help question

  • How to check CComVariant.boolval is valid and extract bool value from it
    B bjorn_ht

    It could be that m_abc->GetProperty returns something other than a bool, so you should also check comVar.vt to see that you really have a boolean.

    C / C++ / MFC help tutorial

  • Win7 - worker thread freeze on call to WaitForSingleObject
    B bjorn_ht

    From the code example I take it that you create the Save2CWGCoilRep thread from the UI thread, i.e. from a menu or button handler function. My guess then is that you have a deadlock: 1. The background thread sends messages to the UI thread. Maybe it tries to display a message box, but it could be anything really. 2. The UI thread is suspended in WaitForSingleObject and can't process the message. It's risky to suspend the UI thread as you don't know when or why messages are posted to it. I would instead protect the critical parts of Save2CWGCoilRep with a critical section and take away the WaitForSingleObject call in the UI thread.

    C / C++ / MFC help c++ lounge

  • CString reference
    B bjorn_ht

    The way you describe it, that string sounds like an object property - the last error message - so it's better and simpler to let it be a member of your class and add an accessor function for it...

    class MyClass
    {
    public:
    bool execute()
    {
    try
    {
    // ...
    throw exception("Testing testing");
    return true;
    }
    catch(exception& e)
    {
    m_lastError = e.what();
    return false;
    }
    }
    CString& lastError()
    {
    return m_lastError;
    }
    private:
    CString m_lastError;
    };

    void tryIt()
    {
    MyClass c;
    if( c.execute() )
    cout << "All well" << endl;
    else
    cout << "MyClass.execute failed: " << c.lastError().GetString() << endl;
    }

    This is safer because you know the CString goes out of scope at the same time your class does, and you still have a CString reference available to use from the rest of your code exactly as before.

    C / C++ / MFC question help
  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups