|
Because you are sending a data stream between two little endian (ENDIAN not ENDING) machines and the sockets dont care what the data is or what order it is in.
This is assuming you are uising windows of course.
If you were doing a windows to xxx (insert your favourite bigendian os here) one end woulod have to translate the data.
==============================
Nothing to say.
|
|
|
|
|
ITboy_Lemon wrote: Is there anyone know this ?
First step with sockets - define the protocol. That specifies how and what is sent. One then uses that to determine how to code the client/server.
|
|
|
|
|
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.
-Sarath.
Rate the answers and close your posts if it's answered
|
|
|
|
|
Hello All,
I have a MFC app developed in VS 6.0
User can open multiple dialogs in this app. Is there a way of keeping track of how many dialogs are open at a given time?
Also, is there a way of getting the handle to each dialog from a central location?
Because the dialogs are opened from different parts of the app, i.e., different files its hard to keep track of all dialogs.
Any sample code will help.
Thanks in advance.
|
|
|
|
|
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.
Use the best guess
|
|
|
|
|
Derive all of your dialogs from a common class. In that base class, override OnInitDialog() and OnCancel() to adjust your counters accordingly.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
DavidCrow wrote: 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.]
--
Harvey
|
|
|
|
|
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?
|
|
|
|
|
Joe Woodbury wrote: However, when we then bring that file into Outlook...
Using code or with Outlook itself.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
With Outlook.
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!
modified 13-Apr-13 22:12pm.
|
|
|
|
|
Hi,
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.
Does anyone have any suggestions?
Cheers,
Charles
Charles Blessing
Software Engineer
NUGEN Audio
|
|
|
|
|
Charles Blessing wrote:
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)...
What about an exclusive read lock, or maybe a write lock?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
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.
modified 12-Apr-13 14:51pm.
|
|
|
|
|
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.
--
Harvey
|
|
|
|
|
Hello All,
I have a MFC app being developed in VS 6.0
This app has a main dialog and from there user can open multiple dialogs. There's a possibility that at any given point there could be 2 or more dialogs open.
Now under a certain condition, i want to make all open dialogs invisible and just show up a LogIn dialog.
I think in order for this to done i need to get the handle of all open dialogs and call ShowWindow(FALSE);
How to get all dialog/window handle?
Thanks in advance.
|
|
|
|
|
Donguy1976 wrote:
Now under a certain condition, i want to make all open dialogs invisible and just show up a LogIn dialog.
Or make the login dialog modal so that interfacing with the other dialogs would not be possible (until the login dialog was properly dismissed).
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Is it possible to get all dialog handles in a app? Or the number of dialogs that are open at a given time?
|
|
|
|
|
the function EnumWindows may help you.This function can enum all the window in the window manager .Or you can use the relationship between the dialog and the apps to meet your point.
|
|
|
|
|
Hello everyone,
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?
|
|
|
|
|
yes
==============================
Nothing to say.
|
|
|
|
|
I think continue is quite okay while goto is evil.
|
|
|
|
|
goto is ok. You can write bad code without it and good code with it, just depends on the code.
==============================
Nothing to say.
|
|
|
|
|
In C there are a very few cases where using it is reasonable, in C++ I wouldn't hire someone who works with goto.
|
|
|
|
|
pasztorpisti wrote: In C there are a very few cases where using it is reasonable
Bollocks.
pasztorpisti wrote: , in C++ I wouldn't hire someone who works with goto.
Dogmatist.
==============================
Nothing to say.
|
|
|
|
|
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!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
