If you want your program to be portable, then any time you send an integer greater than 1 byte in size over the network, you must first convert it to network byte order using htons or htonl, and the receiving computer must convert it to host byte order using ntohs or ntohl. If you're sending computer may be an Intel x86, and the receiving may be a Sun SPARC, and then your program will fail if you don't use htons.
Just add some code so that every time a dialog opens it calls in to a central function which can keep track of them. If these are all modal dialogs I would be interested to know how the app has multiple ones open at the same time.
Derive all of your dialogs from a common class. In that base class, override OnInitDialog() and OnCancel() to adjust your counters accordingly.
More specifically, write a new class MyCDialog which derives from CDialog, and implements OnInitDialog() and OnCancel() as DavidCrow describes, then change all of your existing dlg classes that derive from CDialog to derive from MyCDialog. [Specifically, if a class doesn't derive from CDialog directly, then don't change it.]
I have no idea where to ask this since it covers multiple areas, though the base code is in C++, so I thought I'd post it here.
In short, in part of our product we import AOL emails. The user can then export an email as a [structure storage] MSG file. However, when we then bring that file into Outlook, the From field in the list of emails is not populated. When you click on the message, there is data at the top where the sender information is listed. I've been experimenting with various streams in MSG files and it seems Outlook picks up the "From", for the list, from various places. I've populated ALL of those places with my exported file and Outlook still won't display anything.
Does anyone have any experience with this or have any idea how Outlook processes MSG files?
I may have found a solution. Turns out that a MSG file not only has multiple streams, but a [stream] properties table which lists which streams are valid along with their length. While I'd created the correct stream, I hadn't created a correlating entry in the properties table.
The truly baffling part is that the "from" data is listed multiple times. Why Outlook couldn't pick one of the other ones is baffling.
BTW, the stream id in question was, wait for it, 0x0042!
I have an application that performs some processing on files dropped into a 'watch folder'. The problem I'm having is detecting when the file copy to the folder is complete.
The application needs to run on both Windows and OSX, so ideally I'd like a cross-platform solution, although there is no reason (other than future maintainability) for using the same algorithm on both platforms.
The way I'm doing this at the moment is to wait until I can get a read lock on the file (by just trying to open it), then periodically checking the size of the file to make sure it's not getting any bigger.
Once both of those criteria have been met, I process the file.
The problem I'm seeing is that once in a blue moon, the two criteria will be met when the file is still being copied. My gut feeling is that it's caused by momentary network congestion, but I've been unable to reproduce the issue whilst debugging.
I can probably make it more stable by just throwing a few more checks at the problem and tweaking the time-out values, but the software engineer in me would like a more definitive solution.
One solution I've used is to write the new file to one directory (on the same system) and, when done, moving it to the target directory (on the same system) using the Win32 API, which is an atomic operation.
For one variation, we wrote the file to the same directory, but with an extra extension like ".~tmp" and then did the rename/move operation.
Exactly. That is how browser file downloads work and most other file copy programs that I know of work. The destination filename does not appear until the file is complete.
I'd change your file copy program to copy to a temp file with 'guid-like' name or at least a .~nonsense extension and rename it after the transfer is complete. There are ways to do this, keeping such things as the file timestamp intact.
Today when i was reviewing a part of C++ i noticed continue in some cycles (to be exact i managed to see atleast one example of each cycle with continue)
I remember beeing told that go to and continue shouldn't be used. You can easily do whatever you need with some other tool in c++ semantics.
What do you think? Is using continue a good practice?
I have no doubt a good programmer can write good programs with any syntax element of any language, but that doesn't mean that everyone should! Even the best program deterioates over time. Of all elements of the C/C++ language, goto is the one with the biggest potential for abuse, and the biggest potential for misinterpreting its intended use when maintaining the code. Therefore, even if you're the worlds best programmer, you should never deliberately use goto without a very good reason, and only if the existing alternatives would present a bigger potential for maintenance problems in the future.
You might argue that for throwaway code that you know is going to be ditched within a couple of months there is really no risk, but some of the most long-lived tools were originally designed as throwaway code. Even if the program as a whole gets thrown away, parts of it may be reused elsewhere. We are in an age of VCSs and code reuse; you can't take back code: once you've written it it can not be unwritten!
Last Visit: 31-Dec-99 19:00 Last Update: 7-Dec-23 20:28