VB.NET - Read lines from command line to Windows form possible? - vb.net

Hey Overflow, I have an application which serves as a user interface for a spartan/command line program.
I have the program running on a separate process, and my application monitors it to see if it is responding and how mush CPU it is utilising.
Now I have a list of files in my program (listbox) which are to be sent to the application, which happens fine. But I want to be able to read text from the com-line so as to determine when the first file has been processed.
Com-line says one of "selecting settings", "unsupported format" and "cannot be fixed".
What I want to be able to do is when it says one of these three things, remove item(0) in listbox1.
Is this possible?
I thought of programming an event which handles com_exe.print or something or other, if possible.

Read the standard output from the process.
MSDN Article
Theres an example of synchronous reading from the process in that article.

You might be able to do what you want using the AttachConsole API function as described here. However, maybe an easier alternative would be if you could pipe the output of the command line app to a text file and then your app could just parse the text file (assuming that the command line file wouldn't lock the file completely, I'm not sure about that).
If you don't know how to pipe the output, this page has quite a bit of information.

Related

Open file with VB.NET application (How does my project know which file is being opened?)

I am in the process of making a simple image viewer in VB.NET. I want to be able to open an image with my application. How does VB.NET receive the URL of the file that the user is trying to open?
Seems simple but without knowing key terms, my Google searches are returning completely the wrong things!
You want to inspect the Environment.CommandLine Property
This property provides access to the program name and any arguments specified on the command line when the current process was started.
The program name can include path information, but is not required to do so. Use the GetCommandLineArgs method to retrieve the command-line information parsed and stored in an array of strings.

$model->validate() method is printing 'test'

I am doing a website on YII and PostgreSQL. It is recurrently exiting inside $model->validate() method by printing 'test'. I have searched whole code, There is no exit code on controller , model, beforeValidate(), afterValidate(), even whole project.
Question
How can i debug on such scenario. I have only access to ftp, Netbean as IDE, but no localhost. How to find which file is printing exit code or do you have any idea ?
Thank you,
Ram
Messages can be logged by calling either Yii::log or Yii::trace. The difference between these two methods is that the latter logs a message only when the application is in debug mode.
Yii::log($message, $level, $category);
Yii::trace($message, $category);
When logging a message, we need to specify its category and level. Category is a string in the format of xxx.yyy.zzz which resembles to the path alias. For example, if a message is logged in CController, we may use the category system.web.CController. Message level should be one of the following values:
For more details, refer this YII Tutorial

Writing an Axis2 handler

I am trying to write 2 Axis2 handlers but there is there is something missing I can't put my hand on
The first handler is supposed to start at the very beginning before anything else, it will read the message header, parse the information I want from it and save it to a file then move on.
The second handler will execute after Axis2's Rampart finishes operation, which I assume is after the security phase. It will read the file and execute the logic on it (it wont touch the message contex)
I tried reading the guide on Axis2's website but it was not very beginner friendly, if someone can guide me to a simple way to approach this I would be thankful
You have to make the handlers in order. That is, you have to add the execution phases(In/out/fault flows) and define your handlers in order there. For example, check the axis2.xml, and how they defined the phases/handlers there.
Check this guide

Is a file available to be opened?

Short version: I think I'm asking for a file too soon, but it's pretending like it's ready. Am I missing something?
Slightly longer version: I am writing files to disk. Before I do so, I have the user add some meta data, including the new file name. Once the user is done, the screen goes away and the program writes the file to disk. The user can then look at a list of files. That list is generated by reading the contents of a folder. The new file is in the list of files, but when I try to extract info from the file to display (e.g. file size) the program crashes. As best as I can tell, the crash occurs because, while the file is there in name, it's not available to be read. (By the way, these are small files - a few hundred k.)
First, is it possible that a file shows up in the directory but isn't all there yet?
a
And second, if so, how do I check to see if the file is ready to be read?
Thanks much.
UPDATE:
Thanks. I'll try to add more info. I'm recording an audio file with AVAudioRecorder. The init line is:
soundrecording = [[AVAudioRecorder alloc] initWithURL:url settings:recordSettings error:&error];
The program goes through it's UI updates and metering and all that. When the audio is stopped, I call:
[soundrecording stop];
and when everything else is updated and ready to move on, I call:
[soundrecording release];
soundrecording=NULL;
As far as I understand, this should take care of releasing the file, yes?
Thanks again.
The first thing I would do is confirm that you're right about the file not being ready yet. To do that, sleep your program for a second or two after writing and before reading. A few hundred KB should not take longer than that to be ready.
If it still fails, my guess is that you haven't closed the file handle that you used to write it. It may be unready for reading because the file system thinks you might keep writing.
Usually, the way to check to see if a file is ready is to attempt to open it. If that succeeds, you can read it. Or if it fails with an error, you can handle the error gracefully:
In a command-line utility, you might print the error and quit, and the user could try again.
If it's a background program that should not quit, like a server, you could log the error. You might also try again automatically after a delay. If it's a big deal kind of error, you might want to have the program email you about it.
In an GUI window app, you probably want to show an error dialog or panel, and then give the user an opportunity to retry.
Now that you have added sample code, I can say some more.
First, the class reference seems to say that the stop method will close the file. However it also seems to suggest that there is an underlying audio session going on, and possibly some conversion. I think I recall that the iPhone's Voice Notes app, which probably uses this API, has to do some work to compress a long recording after it's completed.
So I support your hunch. I think that your file may not be closed yet, but on another thread that is processing the recorded data into a proper format to save.
You probably want to set a NSTimer to attempt to open the file every second or so, so that your user interface can perk up when it's done. You probably want to show a "Please wait" sort of message in the meantime, or otherwise let the user know it's working.

Unattended application best practice question

We have an unattended app w/o a user interface that is is periodically run.
It is a VB.NET app. Instead of it being developed as a service, or a formless Windows application, it was developed with a form and all the code was placed in the form_load logic, with an "END" statement as the last line of code to terminate the program.
Other than producing a program that uses unneeded Windows form resources, is there a compelling reason to send this code back for rework to be changed to put the start up logic in a MAIN sub of a BAS file?
If the program is to enter and exit the mix (as opposed to running continuously) is there any point in making it a service?
If the app is developed with a Form do I have to worry about a dialog box being presented that no one will respond to even if there are no MessageBox commands in the app?
I recall there used to be something in VB6 where you could check an app as running unattended, presumably to avoid dialogs.
I don't know whether there are conditions where this will not run.
However, if the code was delivered by someone you will work with going forward, I would look at this as an opportunity to help them understand best practices (which this is not), and to help them understand that you expect best-practice code to be delivered.
First of all, you don't need it to be run in a Form.
Forms are there for Presentation, so it should not be done there.
If you don't want to mess with converting the application a Service (not difficult, but not very easy neither), you shoud create a Console Application, and then, schedule it with Windows Task Scheduler.
This way, you create a Console Application, with a Main function, that does exactly what you need.
Anyway, the programmer could show windows, so there should not be any messagebox. Any communication should be done via Logging to: local files, windows events, database.
If you want more information on any of them, ask me.
If you don't want it to be a service, nothing says that it has to be a windows service. Scheduling it to run via the Task Scheduler or something similar is a valid option.
However, it does sound like the developer should have choose a "Console App" project, instead of a "Windows Forms" project to create this app.
Send it back. The application is bulkier and slower than it needs to be, although that won't be much of an issue. It is somewhat more likely to run out of resources. But the main reason: converting it to a console app is very easy.
If you don't prefer for the Console window to popup, simply do the following.
Create a new class "Program.vb", add a public shared Main() method, and move the "OnLoad" logic from the form to this method.
Next delete the form, and change the project start up object (Available in the project properties window) to use the Program.Main instead of the Form.
This will have the same effect, without the windows forms resources being used. You can then remove the references to System.Windows.Form and System.Drawing.