I tend to do exactly the same mainly because if I need I can transfer my C++ code easily to pure C, C# and into VHDL if working with FPGA's. Some will find our coding quirky because they have not come from that interface background but at the end of the day your code is tight and usually more portable to other languages when you need. Personally I think it's a good trait but those who only write in C++ will argue we aren't using the language to it's full ability.
Do you go the whole hog
I import multiple interfaces into things I never do C++ multiple inheritance at all. I also run my own form of delegates, mine is closer to C# that the standard C++ setup.
The final thing I do is probably very quirky to my embedded background, in that all my interfaces have an abstract event drive message function call set on them. Generally it will be unimplemented but the number of times it has saved my butt when I need complicated exchanges across the interfaces to synchronize them or often I use it for live debugging. Saves hours of time if you can connect to a locked program and actually look at the interface states. To do that you simply setup the event drive message pump in it's own thread and so you can actually push messages to get the interface states even though the program thread may be deadlocked.
The only downside is in team developments some will struggle to understand your code because it isn't the purest standard C++ form. On the couple of times I ever had that happen I just hide the interfaces inside a wrapper class, sort of where your sample is going. I normally don't hide the interfaces they just sit as exposed public on a class because they are an designed as a proper interface after all.
1. I generally use a struct if it's only going to have variables. All access has to public anyway since there are no accessor methods.
2. I also have only a .h file for interfaces. Sometimes I have multiple interfaces defined in one .h file.
Posted to a window when the cursor moves. If the mouse is not captured, the message is posted to the window that contains the cursor. Otherwise, the message is posted to the window that has captured the mouse.
You need to set capture on the mouse if you want the message outside the area. You can grab it when your dialog takes focus or sometimes it is when you select something like select a piece of text to draw. I can't mind read what you are trying to do but you need to set capture on the mouse to get that message outside the client area of the window.
So perhaps start with the simple what starts the fact you want to track the mouse is there an event, a selection process? You want to track the mouse for some reason and whatever starts that process is where you set the capture. When it completes you release the capture. The set capture just needs your window handle and the release call requires no parameters it's a really simple thing and you just need to put the two lines of code in the right place.
The only native window that behaves like that with default behaviour are menu boxes which start the capture when you left mouse click down. They release mouse capture on left mouse click up. That is how you can click an move along menu trees. Perhaps do the same on your dialog so you get the idea. On you dialog handler set capture to start on the left mouse click down and release capture on left mouse click up and you will suddenly see the track outside your window so long as you hold the left button mouse down just like on a menu.
I was doing a job for a company and they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code. You want more there is a whole song and dance you must do. It was a complete pain and then they made the mistake of telling me I could use threads and you could request space for the thread ... so I did apply for 1 thread and got given it.
I offer perhaps the funniest use of a thread ever ... in windows the code would look like this
I figured I would get everything working before dealing with the buffer recycling. It takes a fair bit of work to track what buffers in use and where. What I laughed at was with all the rigor around memory handling I could do it and no-one raised an eyebrow. I mean that is a truely horrible idea.
I will probably recycle one of my memory stream objects and donate it to them because I think the whole manual tracking of buffers is a bit naft and I think just as likely to create program errors as running out of memory.
they don't allow memory allocations to be used you have to request a static block at program start from the memory management unit and then recycle that in your code.
There are good reasons for that:
1. In many cases, it is better to discover that you don't have enough memory at program start than to discover it later.
2. In real-time systems, heap management time can be unpredictable. This makes achieving the time guarantees much more difficult.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
Sorry that is not correct ... running out of memory can be fatal no matter if you allocated it before hand or ran out of it on the heap. In my case I abused the stack which is just as bad.
I am an embedded programmer and I live with low ram implementations in real time systems for a living, and that was the point of my joke at those who think you can frame protection in a standard or a formula. You can't, you need to frame intent and guidelines not specific implementations. You can not create a "safe" or "perfect" specification because you haven't written the code and you don't know the problems.
That whole approach is like 1960's military code specifications and nightmare movie which failed dismally and nobody really codes that way anymore we all use block based approach.
The first public discussion on the new military standards in software I know of was when Boeing allowed hackers to try and hack a "little bird" unmanned helicopter. If you don't know about this stuff that would be a good start point. Hacker-Proof Code Confirmed[^]
As they said you can't hack it and is guaranteed to perform error-free, that isn't a claim it's a provable fact. There are links in the article to the research language F* (F-STAR) and the Project Everest which is Microsofts play in the area of trying to develop better hack free products.
Most new high reliability stuff will follow down those paths for obvious reasons, they can offer guarantees something every other technique can't do.
You are party right any system is better than none ... I understood your intent
Our human systems are always flawed but yeah the new HDL synthesis tool stuff is scary good. Worth playing around with if you have the time and it's fun but quite different way of programming and probably not on Visual Studio until 2050 !!!!
If you allocate memory on the stack... and a recoverable exception occurs in your thread... the memory is correctly released during stack unwinding.
If you allocate memory on the heap and a recoverable exception occurs in your thread... the memory is not released and now your application potentially has a resource leak.
leon de boer wrote:
As they said you can't hack it and is guaranteed to perform error-free, that isn't a claim it's a provable fact.
This is not correct. I have met both Bryan Parno[^] and Jeannette Wing[^] and I was present at the 2014 presentation on campus at Redmond.
Yes, small sections of logic can be statistically proven to be secure. It would not be correct to make the claim of "guaranteed to perform error-free, that isn't a claim it's a provable fact"
If I were to assign a confidence level to what they have achieved I would say "High Confidence".
I have been using SendMessage for interprocess communication.
The Sender Is The Parent console C program. The receiver is a MFC Windows program
All of the sudden it stopped working
I am sure that the windows handle is valid as after The MainFrame is created a (running under the VS debugger) I observe the m_hWnd of the Mainframe. it is the same value returned by the FindWindow (to reterive the windows handle)
I orignally a WM_USER + X and later tried RegisterWindowMessage
The MFC message map (ON_MESSAGE) has message either a #define WM_USER + x or UINT returned
from the RegisterWindowMessage and member handling the message is LRESULT Wparam, Lparam
The issue with SendMessage is that it blocks the calling process until a response is received. Therefore, if something goes wrong in the receiver, the caller tends to hang. So in your situation, my first checks would involve seeing what, if anything, the Mainframe is doing with the message that was sent. Put a breakpoint in the Mainframe's message pump where it catches your registered message, and take it from there. If, by chance, it is not catching your registered message, then there is something amiss with the registration process.
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
Then that tends to indicate an issue with the message registration. Go back (temporarily) to using a WM_USER message, and if that works, then you'll have to look deeper into the way the RegisterMessage is being called. It's been quite a few years since I've done anything with custom windows message, but I have a vague recollection that there is a "gotcha" in there that got me for a while. Can't remember what it was, though, sorry.
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
Are you checking that the return value of RegisterWindowMessage is not zero? Why did you ask for help but did not give the results of GetLastError()?
I recommend avoiding RegisterWindowMessage. Keep in mind that you can only obtain 16,384 RegisterWindowMessage unique identifiers. After that... there are no more system resources for globally unique messages.
Let's imagine that you are writing software to control an oil refinery system.
Maybe you are writing defense department mission critical software.
Perhaps an airplane requires your Windows component for operation.
Imagine if your writing the radar system for an ship out in the sea.
Maybe in these scenarios the operating system is mission critical and should never go down. In these scenarios it is important to avoid RegisterWindowMessage on these systems. Likewise system builders of mission critical software should perform accounting on all software utilizing RegisterWindowMessage.
I orignally a WM_USER + X
Here you chose the wrong message integer range for IPC. Read this: WM_USER = Used to define private messages for use by private window classes
Some possible solutions:
1.) Re-write your IPC and avoid the window message system.
2.) Check if your window message was filtered-out via UIPI. If so, utilize the ChangeWindowMessageFilterEx function to allow the message through.
3.) Use a hammer.
I would have to create a message pump via GetMessage,TranslateMessage,DispatchMessage
Calling the PostMessage function exported from user32.dll results in a NtUserPostMessage system call. This alone should be enough to promote the thread to a gui thread via KiConvertToGuiThread. Note that things are changing as security features are being added to the Microsoft Windows platform. You would need to make sure that PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON is not defined. This security feature disables win32k system calls for a process/thread.
Second What Makes SendMessage with WM_COPYDATA message so special that it is Sanctioned
You are essentially asking:
1.) Why does User Interface Privilege Isolation exist?
2.) Why is the old message model (for inter-process communication) being deprecated ?
Basically the answer is: For a future with better secure computing platform and secure internet connectivity.
Recent hacking attacks described in the media (i.e. democratic national convention) could have potentially been mitigated by defining PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON on browser/e-mail rendering threads. Essentially a 'system call' attack surface reduction.