Solved

Carriage return if run from VB.NET??

Posted on 2006-10-30
7
538 Views
Last Modified: 2013-11-08

Okay, this is a tough one.  I have an old EXE (compiled from FORTRAN) that dumps binary data to a file.  When I run it from a DOS window, it does not put carriage returns after every WRITE statement.  When I run it from my VB.NET program (see code below), it DOES put carriage returns after every statement!!  (This observation is confirmed, wrote a second program to read the binary data with and w/o CRs, and it depends on whether I start it from a DOS window or with the code below.)

This is shocking!  There is something very strange going on.  It's the same compiled EXE, does the VB.NET direct towards a different write DLL or something???  The FORTRAN WRITE commands, by the way, are simple unformatted binary to an open file.

Would MUCH appreciate any ideas as to how this could be happening...  

*****



        Private Sub Go(ByVal bRestart As Boolean)

            Dim t As New Threading.Thread(AddressOf ThreadRun)
            t.Start()

        End Sub


        Private Sub ThreadRun()

            Try

                p.StartInfo.FileName = My.Application.Info.DirectoryPath + "\" + ENGINE_FILE
                p.StartInfo.Arguments = " " + m_Project.INPFile.FileName
                p.StartInfo.UseShellExecute = False
                p.StartInfo.WorkingDirectory = m_Project.ProjectPath
                p.StartInfo.RedirectStandardOutput = True
                p.StartInfo.CreateNoWindow = True
                p.StartInfo.RedirectStandardError = True

                p.Start()
                p.WaitForExit()

                m_LastExitCode = p.ExitCode

                RaiseEvent OnEngineDone()

            Catch ex As Exception

                RaiseEvent OnError(ex.Message, "cEngine.ThreadRun")

            End Try

        End Sub
0
Comment
Question by:riceman0
  • 4
  • 3
7 Comments
 
LVL 18

Expert Comment

by:JoseParrot
ID: 17841888
Hi,

This is not strange, this is Microsoft making things easy to program and difficult to integrate or migrate to other platform. One day, young programmers will find it as a FORTRAN issue, not a Microsoft decision on what is good or not for us. In few years, I think even C++ (the last allowed non-managed Microsoft's programming environment) will disappear, substituted by the slow C#.

About the question, the redirection to the console is made on a line-by-line basis, so the result isn't a surprise at all.

You can use the shell method to avoid such undesirable behavoir.
For example:

' Second argument set to 1 to open the application window normally, with focus
Dim RetVal
Dim MyApp As String
MyApp = My.Application.Info.DirectoryPath + "\" + ENGINE_FILE + _
             " " + m_Project.INPFile.FileName
RetVal = Shell(MyApp, 1)

Jose
0
 

Author Comment

by:riceman0
ID: 17843783

I will try this as soon as possible -- and if it works I will thank you and ask you more about what the heck happened --  but first can I get the same effect by changing to:

p.StartInfo.UseShellExecute = True

0
 

Author Comment

by:riceman0
ID: 17846395

Bad news, using a Shell command from my VB.NET program did not resolve the difference in behavior, still get a CRLF from VB.NET, no CRLF from a DOS window.

Still, I didn't quite follow your explanation, what do you think is going on?  How does this discrepancy make sense?  I would think the machine code that corresponds to a WRITE command is buried in my FORTRAN EXE, and I don't see how .NET could change how it operates... !

0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 
LVL 18

Expert Comment

by:JoseParrot
ID: 17850482
Hi,

Looks like the mistery is clearing...

FORTRAN appends a NewLine at the end of each WRITE command, as its terminator. Different to C programs of the DOS era, as stated at
http://www.tat.physik.uni-tuebingen.de/~kley/lehre/ftn77/tutorial/format.html

DOS waits for both CR and LF (Carriage Return and Line Feed) to go to begin of next line. So, both C and FORTRAN don't start a new line when find a CR.

VB.NET appends its own CR/LF when find a NewLine in the FORTRAN program, as a result of its own environment.

Note that using just a carriage return (Chr(13)) would cause two lines to be overwritten on the screen, since carriage return doesn't advance to a new line. You can use the Environment.NewLine property if you want both a carriage return and a line feed:

"First line" & Chr(10) & "Second line" ' LF only
"First line" & Environment.NewLine & "Second line" ' CR/LF

That is, internally, VB.NET uses Environment.NewLine.
Take a look at
http://msdn2.microsoft.com/en-us/library/system.environment.newline.aspx

Jose
0
 

Author Comment

by:riceman0
ID: 17861588

That rings true, but is there any solution??  I need this EXE to run the same way from DOS and from my .NET process.  That NewLine is readonly, is there no way to tweak the environment of my process?

0
 
LVL 18

Accepted Solution

by:
JoseParrot earned 500 total points
ID: 17863331
The (only?) way I may think is:

1. to redirect the FORTRAN program output to a text file (instead of RedirectStandardOutput),
2. then open and read such file and purge the excedent newlines,
3. show the resulting edited text in the console or elsewhere.

Definitively an ugly programming trick, but this is what appears in my mind.

Jose
0
 

Author Comment

by:riceman0
ID: 17882397

Well, the program output is to files explicitly opened and closed by the FORTRAN program itself, I'm guessing that's not affected by RedirectStandardOutput?

Also, for binary output I won't even be able to tell the excedent CRLFs (i.e., CHR(10) and (13)) from the true data byte=10 and byte=13.  So I'll corrupt my data if I search for and remove them, correct?  (The record size for some files is not uniform.)

How amazingly frustrating.  This is absolutely friggin' absurd.  
0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
Excel object stays open 19 65
SQL400 max size 5 53
groovy example issue 10 66
C# DataGridView_RowsAdded event not firing 1 38
This article will show, step by step, how to integrate R code into a R Sweave document
Does the idea of dealing with bits scare or confuse you? Does it seem like a waste of time in an age where we all have terabytes of storage? If so, you're missing out on one of the core tools in every professional programmer's toolbox. Learn how to …
This video teaches viewers about errors in exception handling.
This tutorial will introduce the viewer to VisualVM for the Java platform application. This video explains an example program and covers the Overview, Monitor, and Heap Dump tabs.

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now