For those new to message boards please try to follow a few simple rules when posting your question.
Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
Keep the subject line brief, but descriptive. eg "File Serialization problem"
Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode HTML tags when pasting" checkbox before pasting anything inside the PRE block, and make sure "Ignore HTML tags in this message" check box is unchecked.
Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
Please do not post links to your question in one forum from another, unrelated forum (such as the lounge). It will be deleted.
Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
No advertising or soliciting.
We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.
Make a client-server architecture. Each window (running as a separate program) is nothing but a display facilty, just like a web browser, with no application logic, no (application) data structures. Everything is done in your server, i.e. your old application deprived of display facilities.
The architecture would be like a database accessed across the web.
My Application takes very less data (configuration) from text files, rest are all calculations done every second for around 20000 tags or values. If I do it using TCP/IP Sockets that my application may be overloaded for each window. Is there any other option in MFC?
I do not work with MFC myself, so this is just results from a little documentation searching.
TCP/IP is certainly not a lightweight mechanism, but pipes are. In the original Unix design (from the early 1970s), the processes in either end had to have a common ancestor, creating the pipe, but later we got named pipes, CreateNamedPipeA function[^] so that arbitrary processes can communicate across them. This has far less overhead than an TCP/IP socket.
There is the opposite function: To make a disk file look like RAM, a "memory mapped file". In the old days, you couldn't do that from C#, you had to use C/C++. Now I find only the dotNet version (at MemoryMappedFile Class[^]), but of course it is still is provided in C/C++; I just can't find it (I would think that CSharedFile and CMemFile are thin layers on top of that mechanism.) You may be more clever than I am in finding the C++ equivalent. It is there, somewhere...
A memory mapped file does not require an underlaying disk file; you use the same facility for creating a data segment accessible from multiple processes. Using a shared segment, a.k.a. a memory mapped file, is certainly the fastest way to exchange data between processes, comparable to threads accessing shared data within a process: The memory management system handles it. The greatest advantage, compared to a file/pipe solution: You don't have to serialize (or marshal, or whatever your call it) your data structures, but can access them "as is". For pointer based structures, all processes accessing the shared data segment obviously must map it to the same logical address. Equally obvious: You are responsible for all synchronization yourself, which must be done with semaphores (or whatever higher level mechanism) at system level, available to all processes. It will be somewhat more costly than a single-process implementation, but it doesn't have to be much, especially if there a single process (the server) updating the data, other processes only reading/displaying them.
There is an option in MFC to create application type as "multiple top level documents" which meets my requirements.
Can you please suggest how to convert my application from "Multiple Document Interface" type to "multiple top level documents" type.
I am a beginner in programming and I am trying to solve this problem using queues. I can't seem to come with an idea to solve it.
Can you help please, it is a problem just to learn about how to approach queue problems.
Well, I understand that "Brevity is the soul of wit.", but could you explain more specific what your problem is and the relation between "Abort Retry Ignore" and "Structured Exception Handlers" in this context?
There is no such thing as "Abort Retry Ignore" per se.
The closest I can think of is one old machine I knew: A fault handler would receive the address of the faulting instruction and a pointer to the register block, with the program pointer set to the following instruction. So, default handler return was "Ignore". Copying the faulting address to the program counter before handler return would be "Retry" at instruction level. Copying the return address from the stack frame pointed to by SP would be "Abort" at the function call level. (The handler could traverse the stack to find an outer return address.)
This is "Abort Retry Ignore" at instuction level, not directly appliccable to SEH. Actually, I am not certain that compiler writers made much use of the mechanisms at all. This machine offered several other features intended to make life easier for the software, but the software guys said "Nah. We'll do it our own way".
So the pcontext structure (which is in the pxeception pointer parameter structure) which has the registers is what I can manipulate the os windows will use those to continue processing
on abend the eip points to he instruction after the abend backing up the eip would allow me to do a retry
This machine I mentioned was not a Windows machine, and not an Intel architecture. At instruction / register level, you cannot expect any one-to-one mapping of concepts.
Also, you cannot map software concepts, like an exception handler, directly onto the interrupt system of every different CPU architecture. Often, a compiler will add a lot of its own to the basic hardware mechanisms. E.g. most exception mechanisms identify the proper handler by the static nesting, but that is within one function. Languages with nested function definitions, "Pascal style", may define handler identification and/or propagation by the overall nesting structure, requiring the static link in the stack frame to be followed. Unless you know every tiny detail of how the compiler generates code, and the runtime handler library (which may be written in assembly code and diverge from the compiler's code generation style), manipulating return addresses and other register contents is likely to mess up your system completely. (And don't forget that hardware fault handlers may be running in privileged mode, allowing you to really mess up your system!)
So, if you work at software SEH level, stick to that level, and don't mess with registers and return addresses.
(My comment was meant as an aside to the "Abort, Retry or Ignore?" not existing per se - just to illustrate that you can get close. I didn't intend it as a viable solution to your problem!)
What I’m saying is the context structure which windows passes me in the SEH with the registers and eip is What windows will use to resume execution I can set the eip to the next instruction to be executed right ?
If you retry, what makes you think the outcome will be any different? If you do it automatically, there's a good chance you'll end up in a retry loop. If you continue with the next instruction, well, it's not called undefined behavior for nothing. It's best to generate a stack trace to help you debug and fix the problem. I've written an article[^] about this.