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.
I have a problem with redirect console app output and input. The problem is that any example I found does not work for me. I want to develop WPF GUI for a console app. This is the example code to redirect output:
ProcessStartInfo start = new ProcessStartInfo();<br />
start.FileName = "C:\\myapp.exe"; // Specify exe name.<br />
start.UseShellExecute = false;<br />
start.RedirectStandardOutput = true;<br />
using (Process process = Process.Start(start))<br />
using (StreamReader reader = process.StandardOutput)<br />
string result = reader.ReadToEnd();<br />
So I did some reverse engineering on the console app and I found that this app is compiled using Microsoft Visual C 6.0. The app uses WriteFile to output to the console and first argument passed to the function equals 7.
I wrote the example code:
I do not understand why this: WriteFile(hStdout, s, (DWORD)strlen(s), &dwBytesWritten, NULL); (hStdout equals 7 checked by debuger) is redirected using my above example code or TestCON.exe > test.txt but this WriteFile((HANDLE)0x00000007, s3, (DWORD)strlen(s3), &dwBytesWritten, NULL); is printed always on the console.
Any suggestions how can I redirect any output to my GUI app?
It's in just about every AllocConsole example on the net
AllocConsole(); //Allocate a console
freopen("CONIN$", "r", stdin); // Redirect standard in
freopen("CONOUT$", "w", stdout); // Redirect standard out
freopen("CONOUT$", "w", stderr); // Redirect standard error
setbuf(stdout, NULL); // Clear the buffer from standard out
You may want to use the new freopen_s etc calls to avoid the warning.
CONIN$ and CONOUT$ are the console input and outputs associated to your program as distinct from the standard handles.
That isn't a problem you have redirected the standard file handle to the windows console created.
Try to read the console handles document and understand what is happening.
Visual studio does exactly that it executes a windows binary file and redirects the output to the console plane that is in visual studio.
Your binary file will use standard input/output and it's been redirected up to your console window.
i am trying to write a code to solve Laplace equation using Successive
Over relaxation(SOR)on a NXN matrix
boundary condition is X^2-y^2
i dont know how to set this boundary condition on the Mesh created by me
here is the code
import numpy as np
from pylab import *
import matplotlib.pyplot as plt
import matplotlib.ticker as ticker
L =[for i in range(2)]
N=int(input("Enter a number N for N x N grid: "))
x,y = np.meshgrid(xx,yy)
phi_new = copy.deepcopy(phi)
for w in np.linspace(1,2,11):
for i in range(1,N-1):
for j in range(1,N-1):
Sumresidual=0for i in range(1,N-1):
for j in range(1,N-1):
ax = plt.axes()
plt.ylabel('|| residual ||')
plt.title('effect of w on residual')
... anything. Guessing is not generally a good strategy for fixing problems. You need to be sure what the problem is first. Maybe if you show the code where the problem occurs, and a few more details, we could make some useful suggestions.
if stepped thru the code in Assembler after the function prologue by subtracting BP - SP = stack size right ?
I added code to a source file in Hercules cpu.c thing is its a makefile build which very confusing I was wondering if there isn't -F or /F flag for the stack size I guess it would default to some number my local variables and parameters would make the stack a little over 300 bytes, which is not too big
I am trying to figure to determine where in the makefile is the compile for CPU.C
I think we are talking at cross-purposes. What you are referring to is a function's frame size, which is a portion of the thread's stack. The frame will be created large enough for all the locally declared variables in that function, so you need to look at the source code to see why it is not large enough, or why it is being overwritten.
The makefile may be using an inference rule for cpu.c, so you cannot always find a specific line which references it. But you should be able to find a reference to it somewhere in the Makefile (or any of its included subfiles). However, as I mentioned, you still need to diagnose the actual problem, and changing the stack size for the final application is unlikely to make any difference.