I don't know if it is the right place for this topic, in case it is not right please move it in right location of the forum.
What I am trying to achieve is to execute an external program from a gui. When user click the button, it run the program. My work is based from this documentation that I found using Google. It is the amiga wiki page. Here is the link of the page:
http://wiki.amigaos.net/wiki/Executing_External_Programs
First i created this simple program to test if it works and indeed it works. When I place this little program inside the directory where the program is, it works without problems but when I insert this little piece of code inside my main project, it runs but the main window of the program trashes and then the system freezes. I suspect I need more code to add but I don't know where to look at..
Test program:
Code inside main project:
before using the System() function I tried to use the WBOpenObject() function but i wasn't able to pass argument to the program so I tried the System() function thinking it was the right function to use but I have the problem above.. Any hint on where to find proper example or documentation?
Thanks,
Maybe I solved the problem but tell me if my solution is the right one..
I used this code when the user press the start button:
I changed from IDOS->Open() to IDOS->FOpen(). This function use buffered file so I guessed that could be the reason of trashed window and error when quitting the emulator..
Now i have no more error and trash window when i run the program.. It works both on shell and workbench.
Thanks,
Davide
I would like to mark my question as "solved" but I cannot edit my first post.. By the way the problem is solved :)
Hi, I do use this to execute/launch Time prefs. from a GUI:
AOS4.1/SAM460ex/PPC460EX-1155MHZ/2048MB/RadeonHD6570/SSD120GB/DVDRW :-P
Thanks Jabirulo :)
Nube, before you go I noticed this. You open a console window for input but not output. Which I see is the standard but strange looking way for providing a console. It's unusual to have a window for input and no window for output. You set SYS_Asynch to TRUE which means the system will close your file so you will need to leave it open. Using Open() is fine for that purpose. But then it looks like your program exits immediately without closing the GUI. It is a test program but using FOpen() over Open() shouldn't make any difference so something else is amiss.
@hypex
According to the dos autodocs, SystemTags will copy SYS_Input to SYS_Output if SYS_Output is 0 (zero). However, he needs to check the SystemTags() return value and close the console if SystemTags() returns -1 (error). If SystemTags() succeeds, SystemTags() will close the console (in SYS_Asynch mode) as you pointed out. If SYS_Input is specified as 0 (zero) then SystemTags() will use NIL: for input.
Could that be why his window is being trashed?
X1000 - OS 4.1FE
@Xenic @hypex
Thanks for the reply. I tried using FOpen() and it immediatly solved the trashed window problem but I have to check, as xenic said, the return value to see if there is an error. About the console, as Xenic said, I red in the Autodocs that if you set SYS_Asynch TRUE and SYS_Output 0 it will copy Input to Output so I guess it is correct..
When I exit the emulator (with esc key, it is the MAME) it returns to the gui so I can run another game. Then when I quit the gui it free all the allocated resources..
Now I have no more trashed window by the way I have to check the return code from SystemTags as you said :-)
Thanks for the informations! I'll keep you updated!
P.S.: In the meanwhile I added menu with icons and shortcuts and an infowindow using the new infowindowclass
:-)
Just remember, not everyone will have infowindow.class installed. So unless you only target users with the Enhancer package installed, or provide some other method of showing "About", there may be issues.
Of course, if you are going to provide an alternate "About", it kind of makes using infowindow.class pointless really.
Simon
@Nube
A few minor niggles about your code occurred to me, although they won't affect the problem at hand:
1: both in line 70 and line 501 you define a
struct Window *window., of which the first one, line 70, may be removed.2: starting from line 682 you close dos.library preceded by dropping its interface, but hey, you didn't anywhere open c.q get them. And it is not necessary to open c.q. close this library and consequently get and drop the interface as the startup-code will do this for you. You may delete lines 682 upto and including line 687.
3: in line 511 you state
while (!done). You assume here that one of the boolean states applied to this variable is 0.'done' is a boolean and has therefore 2 defined states, 'TRUE' and 'FALSE', and 65534 undefined states. Only set the variable with either 'TRUE' or 'FALSE' and test the variable against either 'TRUE' or 'FALSE' (in UNNEGATED form!). 'TRUE' is not equivalent to '!FALSE' and 'FALSE' is not equivalent to '!TRUE'. Also avoid, for the same reason, testing with a negated comparison, likewhile (done != TRUE). Use:while (done == FALSE)and never fall prey to the old April's fool-prank of assigning differnet values to the macro's TRUE and FALSE. I'm speaking here from experience...OldFart
Thanks for the usefull informations :-)
@OldFart:
3. this is nit-picking. In C language zero is defined as boolean false and every non-zero value is treated as boolean true. If you set done to 27, !done will still be 0 and thus false. And !0 is 1.
I agree that you should never do done == TRUE or done != TRUE, but done != FALSE or !done is perfectly ok.
I'd even prefer !done because the ! operator converts the integer with one false and many true values into a bolean with exactly one false and one true value.
Thanks Thomas! and thanks to all of you :-)
@xenic
I agree. Another thing to check.
I wonder if it is. But it has more serious problems. Which I'll point out below.
@Nube
Using the above code as an example, though it would have changed by now, I was referring to this on line 590:
return IDOS->SystemTags(command,This will call SystemTags(), exit the main() routine, and pass the result to DOS. In fact I noticed when ever there is a fail in the set up it will call
return(0);. This will exit immediately without freeing any resources. Very bad. :-DBut it gets worse. I compiled your code on my X1000. It doesn't even run. Well I mean it doesn't load up a GUI. The CPU meter goes up for a second and then it totally freezes my system up. I happened to have my debug terminal attached and it killed the system. :-o
It gets to the point of "Get IntegerBase, Integer Class opened" and then full stop. So not only is something amiss, something is very amiss, Very, very, amiss. :-)
I tried to debug it but DB101 just crashes. Which it always does for me even on simple code. First class debugger just a slight embellishment there. Which is unfortunate as clearly a lot of work was put into it. GDB only for us and we don't even have the GUI version of GDB. :-?
Look into this pice of code:
"nodetexts< em >" is wrong and should be "nodetexts[ i ] "
Looks like embedded texteditor changes [ i ] into < em >, just do a find&replace for such piece of code.
AOS4.1/SAM460ex/PPC460EX-1155MHZ/2048MB/RadeonHD6570/SSD120GB/DVDRW :-P
@jabirulo
Thanks, yes that solves the crash. I saw that. I thought some formatting code was embedded in there and removed it. This was on top of all the '240' codes in it. Looks like it needs a downlink for downloading actual source posted.
In any case now it runs through and just exits. This is a large chunk of code. I wonder if it worked at all? I'm about to get GDB out again and see where it fails. But last time I ran it through GDB it just ran the code when I told it next. Shouldn't do that.
That code is now outdated but you need an image to insert and use in the bitmap inside the window layout that's why it doesn't open the window. About the trashed window it is due to a function that i replaced so no more crashes at all. About the listbrowser i think the problem is the parser of the site that replaced the with ..
@Rigo
Sorry for the late reply I didn't see your answer sorry... yes I though about the About window and I am thinking to check the infowindow base pointer. If it is not availabe, (the infowindow class is not installed on the system) it will open a normal window with information on it.
:-)
@Nube
Ah okay. Well as suspected the code is obsolete. And on that note where was the error about the image. ;-)
What replacing Open() with FOpen()? If so, then your problem isn't fixed, as using Open() is standard for this purpose. Something else is wrong if you can't use Open() to open a console.
Your options would include that as well as an EasyRequest() or you can use a TimedDosRequester(). :-)
Yes, as I replaced FOpen against Open the problem went away. By The Way I have to recheck it again as, as I said before, the code changed alot so i have to recheck it with open function
@Hypex
Just let you know that now with the updated code, it works both with IDOS->Open() and IDOS->FOpen().
@Nube
Well that's strange. I wonder what changed in your code then? Still I'd like to know why GDB doesn't debug on my system and just runs through. I found this using your code. But your code wouldn't be causing GDB to break and just run through without stopping. It's my problem, I'll deal with it. Good you got it going. :-)