Search Results

Search found 7 results on 1 pages for 'mordachai'.

Page 1/1 | 1 

  • What's the boost way to create a functor that binds out an argument

    - by Mordachai
    I have need for a function pointer that takes two arguments and returns a string. I would like to pass an adapter that wraps a function that takes one argument, and returns the string (i.e. discard one of the arguments). I can trivially build my own adapter, that takes the 2 arguments, calls the wrapped function passing just the one argument through. But I'd much rather have a simple way to create an adapter on the fly, if there is an easy way to do so in C++/boost? Here's some details to make this a bit more concrete: typedef boost::function<CString (int,int)> TooltipTextFn; class MyCtrl { public: MyCtrl(TooltipTextFn callback = boost::bind(&MyCtrl::GetCellText, this, _1, _2)) : m_callback(callback) { } // QUESTION: how to trivially wrapper GetRowText to conform to TooltipTextFn by just discarding _2 ?! void UseRowText() { m_callback = boost::bind(&MyCtrl::GetRowText, this, _1, ??); } private: CString GetCellText(int row, int column); CString GetRowText(int row); TooltipTextFn m_callback; } Obviously, I can supply a member that adapts GetRowText to take two arguments and only passes the first to GetRowText() itself. But is there already a boost binder / adapter that lets me do that?

    Read the article

  • How to genrate a monochrome bit mask for a 32bit bitmap

    - by Mordachai
    Under Win32, it is a common technique to generate a monochrome bitmask from a bitmap for transparency use by doing the following: SetBkColor(hdcSource, clrTransparency); VERIFY(BitBlt(hdcMask, 0, 0, bm.bmWidth, bm.bmHeight, hdcSource, 0, 0, SRCCOPY)); This assumes that hdcSource is a memory DC holding the source image, and hdcMask is a memory DC holding a monochrome bitmap of the same size (so both are 32x32, but the source is 4 bit color, while the target is 1bit monochrome). However, this seems to fail for me when the source is 32 bit color + alpha. Instead of getting a monochrome bitmap in hdcMask, I get a mask that is all black. No bits get set to white (1). Whereas this works for the 4bit color source. My search-foo is failing, as I cannot seem to find any references to this particular problem. I have isolated that this is indeed the issue in my code: i.e. if I use a source bitmap that is 16 color (4bit), it works; if I use a 32 bit image, it produces the all-black mask. Is there an alternate method I should be using in the case of 32 bit color images? Is there an issue with the alpha channel that overrides the normal behavior of the above technique? Thanks for any help you may have to offer! ADDENDUM: I am still unable to find a technique that creates a valid monochrome bitmap for my GDI+ produced source bitmap. I have somewhat alleviated my particular issue by simply not generating a monochrome bitmask at all, and instead I'm using TransparentBlt(), which seems to get it right (but I don't know what they're doing internally that's any different that allows them to correctly mask the image). It might be useful to have a really good, working function: HBITMAP CreateTransparencyMask(HDC hdc, HBITMAP hSource, COLORREF crTransparency); Where it always creates a valid transparency mask, regardless of the color depth of hSource. Ideas?

    Read the article

  • Win32: BitTest, BitTestAndComplement, ... <- How to disable this junk?

    - by Mordachai
    WinNT.h has the following lines in it, in the VS2008 SP1 install: #define BitTest _bittest #define BitTestAndComplement _bittestandcomplement #define BitTestAndSet _bittestandset #define BitTestAndReset _bittestandreset #define InterlockedBitTestAndSet _interlockedbittestandset #define InterlockedBitTestAndReset _interlockedbittestandreset I have a number of templates that are based on BitTest<() Does anyone know of a simple way to disable these #defines? Oftentimes MS does provide a #define XXX symbol which, if defined, will disable some offending portion of their header - e.g. NOMINMAX. I have been unable to find such a solution to the above problem. If you share frustration with Microsoft's many dubious choices, the read on. If not, stop here. ;) Editorializing: Why couldn't Microsoft just use the _bittest itself??? Or why couldn't they use BITTEST like every knows you should - always use all-caps for macros! Microsoft is still #defining things in 2010?! WTF?

    Read the article

  • MFC/WIN32: mouse hover highlight in listctrl

    - by Mordachai
    The ListView control of Windows Explorer gives a highlight to whatever item is under the mouse, without affecting the current selection. This helps enormously with relating what item a given tooltip applies to within a listview - especially in report mode. However, I am currently unable to find any APIs that would give my MFC application's CListCtrl that same behavior. Extended styles only have LVS_EX_TRACKSELECT, which actually alters the current selection (yuck!). Does anyone know how to provide a standard CListCtrl (or whatever that actually sits on top of) the mouse-hot-tracking capability? I found some articles on how to provide per cell and per row tooltip text, but its hard to tell what the tooltips relate to without something highlighting...

    Read the article

  • What /else/ causes this?

    - by Mordachai
    MFC Toolbox Library.lib(SimpleFileIO.obj) : error LNK2005: _wcsnlen already defined in libcmtd.lib(wcslen_s.obj) fatal error LNK1169: one or more multiply defined symbols found This is driving me nuts. Normally, one would get this if the various projects that are a part of their solution do not agree on which CRT to use (single threaded, multi-threaded, release or debug). However, I have been over this thing about 500 times now, and they all agree. Background: this is a VS 2010 project just converted from VS 2008. MFC Toolbox Library.lib is set to compile as a static library, using /MTd, as is the target .exe I am trying to compile in this solution. Further, the solution that this is being converted from (VS 2008) already compiles & links properly!!! So it's not like that there is a disagreement between the two .vcproj's - or at least there wasn't before the conversion. Furthermore, the MFC Toolbox Library is used by about 25 other projects in another solution - and in that solution (Master Build English) it compiles & links against those other projects without complaint in both debug and release targets. I have just spent the last hour going over every single project property for this target project (Cimex Header Viewer) vs. several different target exe projects in Master Build English solution - and I cannot find a difference. They appear to be identical, excepting that they're different names. I've tried doing a clean & build all. I'm simply out of ideas. Does anyone have a thought on what else I might investigate??? I think I'm ready to start chewing glass. :(

    Read the article

  • C++: How do I correctly register and unregister file type associations for our application (programa

    - by Mordachai
    Time was when you set file associations in: HEY_CLASSES_ROOT\<.ext However, that seems to be possible, but an incomplete solution anymore. There are additional associations throughout the registry. For example: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\KindMap HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Extensions And all of the above, but by HKEY_USERS\ And Microsoft added their Set Default Associations control panel applet, which controls... what? I'm looking for a white paper, or discussions on: "How is a modern, Windows XP-Windows 7 compatible application written in C/C++ supposed to register and manipulate its file associations without interfering with Explorer, User-Settings, or the Default Associations cpl"

    Read the article

  • How to delete ProgIDs from other user accounts when uninstalling from Windows?

    - by Mordachai
    I've been investigating "how should a modern windows c++ application register its file types" with Windows (see http://stackoverflow.com/questions/2828637/c-how-do-i-correctly-register-and-unregister-file-type-associations-for-our-ap). And having combed through the various MSDN articles on the subject, the summary appears to be as follows: The installer (elevated) should register the global ProgID HKLM\Software\Classes\my-app.my-doc[.version] (e.g. HKLM\Software\Classes\TextPad.text) The installer also configures default associations for its document types (e.g. .myext) and points this to the aforementioned global ProgID in HKLM. NOTE: a user interface should be provided here to allow the user to either accept all default associations, or to customize which associations should be set. The application, running standard (unelevated), should provide a UI for allowing the current user to set their personal associations as is available in the installer, except that these associations are stored in HKCU\Software\Classes (per user, not per machine). The UN-installer is then responsible for deleting all registered ProgIDs (but should leave the actual file associations alone, as Windows is smart enough to handle associations pointing to missing ProgIDs, and this is the specified desired behavior by MSDN). So that schema sounds reasonable to me, except when I consider #4: How does an uninstaller, running elevated for a given user account, delete any per-user ProgIDs created in step #3 for other users? As I understand things, even in elevated mode, an uninstaller cannot go into another user's registry hive and delete items? Or can it? Does it have to load each given user hive first? What are the rules here? Thanks for any insight you might have to offer! EDIT: See below for the solution (My question was founded in confusion)

    Read the article

1