| |
Problems opening window in C |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Colin Ward |
Message #117625, posted by ColinWard at 07:56, 7/5/2011 |
Member
Posts: 16
|
Recently I have obtained for myself a Beagleboard and the set of programmer's reference manuals for RISC OS and have started experimenting with some basic WIMP programming in C.
Have a look here:
http://www.codehq.org/wimp1.c
Excuse its messiness - this is experimental (and exasperated!) code.
I just spent a few days trying to get this to work, but no matter what I tried I got bizarre results, mainly that the window had some very strange behaviour such as the scrollbars being larger than the window, the borders not getting drawn and it was crashing at shutdown. No matter what I changed it didn't seem to make any difference! Even taking into account that I am a beginner RISC OS programmer, I am a very experienced programmer in general so it didn't make sense that it was so hard to open a window!
Then last night I had a breakthrough. Have a look in open_window() for the following line:
printf("work_flags = %x\n", new_window->work_flags);
When I added this line to check that my flags were set ok, MY WINDOW OPENED PERFECTLY!!! Taking away this printf I was back to my usual problems. The window still gets corrupted and crashes the system when dragged but this is at least a start.
So it would seem that rather than me being a newbie and stuffing up my Wimp_OpenWindow call somehow, it is the compiler at fault. It is as though there is an optimisation bug and the values that I am writing into the variables in my struct window are somehow not being written properly. So that's why no matter what I change in my code, the behaviour of the window when I call Wimp_OpenWindow was always the same (wrong) and never reflects my changes to the window structure. Calling printf seems to "flush" my changes into the window structure. Could this be a GCC bug? This is using the version of GCC found here:
http://www.riscos.info/index.php/GCCSDK
And it is running on a Beagleboard. I know that my program is right because I got a BASIC version of the same program from a Wimp programming book that works and my C program is an almost perfect conversion of this working BASIC program, right down to the precise values of variables in the window structure/block and the functions that are called in response to Wimp_Poll.
Could someone try my posted version in Acorn C and tell me if it works? This would be the best test as to whether it is my program or the compiler (I just cleaned up the program for clarity but it should still compile)!
Any suggestions would be most welcome! |
| |
 [ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #117626, posted by arawnsley at 09:50, 7/5/2011, in reply to message #117625 |
R-Comp chap
Posts: 600
|
I tried your code in Norcroft (RISC OS Open compiler) and it flagged up a few errors that it didn't like - cast of string (task name) to int (regs.r2). This was an easy fix.
It also objected to setting window = mem_block on the grounds of non-equal pointer (similarly for open_win). Replacing these with separate mallocs allowed the code to compile, and ran without a hitch with/without printf.
I must admit I tend to use one of the variety of wimp libraries that exist (there's plenty of demo code around to get you off the ground quickly) and concentrate on my own app code. |
| |
[ Log in to reply ] |
| |
|
Paul Johnson |
Message #117627, posted by nodoid at 15:58, 7/5/2011, in reply to message #117625 |
Member
Posts: 69
|
Hi,
This was written ages back, but it might help...
http://www.all-the-johnsons.co.uk/riscos/introduction.html
(takes you through writing WIMP apps in C with source code included) |
| |
[ Log in to reply ] |
| |
|
Steve Fryatt |
Message #117628, posted by stevef at 17:15, 7/5/2011, in reply to message #117625 |
Member
Posts: 18
|
It compiles and runs OK with GCC on an Iyonix, with a similar set of warnings to the ones reported by Andrew. I haven't exhaustively checked your code, but you're certainly confusing window and task handles in your exit sequence and I wouldn't like to say that you're not doing other stuff like that elsewhere (there were certainly some odd abuses of pointers, which while probably functional will come back to bite you later on).
However, that's missing the point. You say that you copied the code from a working BASIC implementation: that's not a good idea. BASIC and C are completely different, and IME the biggest mistake that you can make when moving to C is to try and do it how you did it in BASIC. The quicker you forget that, the quicker you'll start to see the benefits of using C over BASIC. In particular, claiming and releasing memory blocks in C is much easier than in BASIC, so don't even think of using a shared memory block as you're doing here.
The other thing, as Andrew also mentions, is that using some of the pre-existing libraries in C is a Very Good Idea. Even if you don't want to go down the route of an event-driven library just yet, using OSLib to wrap up the SWI calls and give you the necessary pre-defined types and structures is a very good idea. See http://ro-oslib.sourceforge.net/ for details.
I've reworked your code using OSLib's Wimp facilities, and the result is at http://www.sfryatt.eclipse.co.uk/temp/wimp.html -- hopefully it makes sense, and is a little clearer. You'll need to get a copy of OSLib from the site above and point GCC towards it in order to compile it, however. |
| |
[ Log in to reply ] |
| |
|
Steve Fryatt |
Message #117629, posted by stevef at 17:27, 7/5/2011, in reply to message #117627 |
Member
Posts: 18
|
This was written ages back, but it might help...
http://www.all-the-johnsons.co.uk/riscos/introduction.html I'd still strongly advise the OP to use something like OSLib to clean up all the SWI calls and simplify handling all of the different data blocks that the Wimp requires. OSLib also removes the need to remember all of the magic numbers that the Wimp requires to activate additional features: it just provides a different function veneer with additional parameters as necessary. |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #117630, posted by arawnsley at 18:30, 7/5/2011, in reply to message #117629 |
R-Comp chap
Posts: 600
|
I completely agree with what Steve is saying here. I'll just add that it shouldn't be necessary to ditch the BASIC programming book altogether - all the material on how the wimp works, messages, events and so on will remain just as valid as ever. However, using a suitable library will provide you friendlier function calls to make use of this information, making your code more readable, and easier to debug.
It is *rare* that a problem is a compiler/library issue if you're using something well tested (such as the tools mentioned already).
Also, don't be afraid to look for example code on the net, or as part of things like Paul's tutorials. Many software authors (but not necessarily all - don't be put off!) will also provide you with chunks of code to help you learn, if required.
Most of us learned by fiddling with pre-existing bits of code and adapting them to learn how things work, and it's still a very valid way of working.
In many ways, starting from "first principles" is one of the hardest ways to learn to program. It is very easy to end up with a head full of concepts, but not really understand how to apply them. |
| |
[ Log in to reply ] |
| |
|
Paul Johnson |
Message #117632, posted by nodoid at 11:06, 8/5/2011, in reply to message #117629 |
Member
Posts: 69
|
This was written ages back, but it might help...
http://www.all-the-johnsons.co.uk/riscos/introduction.html I'd still strongly advise the OP to use something like OSLib to clean up all the SWI calls and simplify handling all of the different data blocks that the Wimp requires. OSLib also removes the need to remember all of the magic numbers that the Wimp requires to activate additional features: it just provides a different function veneer with additional parameters as necessary.
To an extent, I would agree with using OSLib or WimpLib or any other of the handling libraries out there. However, given the nature of the code example posted, it looks more like the OP is trying to learn from the ground up. Libraries, while good, don't always help in this respect. |
| |
[ Log in to reply ] |
| |
|
Paul Johnson |
Message #117633, posted by nodoid at 11:08, 8/5/2011, in reply to message #117630 |
Member
Posts: 69
|
In many ways, starting from "first principles" is one of the hardest ways to learn to program. It is very easy to end up with a head full of concepts, but not really understand how to apply them.
Couldn't agree more - I'm trying to get my head around Dublin Core and a few other things like that still. It's getting there, but not fully there yet. |
| |
[ Log in to reply ] |
| |
|
Steve Fryatt |
Message #117634, posted by stevef at 11:36, 8/5/2011, in reply to message #117632 |
Member
Posts: 18
|
I'd still strongly advise the OP to use something like OSLib to clean up all the SWI calls and simplify handling all of the different data blocks that the Wimp requires. To an extent, I would agree with using OSLib or WimpLib or any other of the handling libraries out there. However, given the nature of the code example posted, it looks more like the OP is trying to learn from the ground up. Libraries, while good, don't always help in this respect.
While that's true of the higher level libraries, OSLib just provides a clean interface to the underlying SWIs without having to go via the messy _swi() or its equivalents. It allows you to learn from the ground up without drowning in unnecessary syntax -- exactly what is required here. |
| |
[ Log in to reply ] |
| |
|
Colin Ward |
Message #117653, posted by ColinWard at 07:55, 10/5/2011, in reply to message #117628 |
Member
Posts: 16
|
Firstly let me say a big thank you to everyone who has responded.
Let me then say I'm on the verge of giving up my foray into RISC OS - this is SO frustrating!
To put things in perspective I'm a newcomer with a Beagleboard and GCC so I suppose I'm not entirely "normal" in that I'm trying to use a non official compiler on a non official hardware platform and I don't have a copy of the official compiler, so that makes my point of entry rather steep!
The reason I'm using "raw" _swi() calls is because I have not been able to find an OSLib that works with my version of GCC (or at least I don't know how to make it work). It would seem that it is aimed at previous versions of GCC and/or the Acorn compiler. When I try to link with oslib32.o using GCC I get the following error:
oslib/oslib32.o: file not recognized: File format not recognized
This is using:
gcc -I oslib wimp2.c oslib/oslib32.o
I assume the .o means it's an object file and not a .a archive? Any suggestions how to link to this?
As I couldn't link to the oslib32.o object file I changed Steve's oslib based example so that it still uses the same oslib #defines and structures but uses _swi() calls to call into the OS. But I get similarly failed attempts to open my window. I MUST be missing something here! I'm sure that I'm putting my parameters in the correct registers for the _swi() calls as I've checked them against other examples about 50 times!
It also doesn't make sense that other people in this thread have been able to compile and run my original example when it won't work for me. Does anyone else here use GCCSDK 4.1.1 on a Beagleboard? Maybe that combination is broken?
[Edited by ColinWard at 09:00, 10/5/2011]
[Edited by ColinWard at 13:55, 10/5/2011] |
| |
[ Log in to reply ] |
| |
|
Colin Ward |
Message #117654, posted by ColinWard at 08:07, 10/5/2011, in reply to message #117628 |
Member
Posts: 16
|
It compiles and runs OK with GCC on an Iyonix, with a similar set of warnings to the ones reported by Andrew. <professional_pride>Ignore the warnings - they are only as this is very exasperated code and not due to my not caring or being a crappy programmer.  </professional_pride>
Could you please do me a favour and try dragging the window around? One of the problems that I have is that even if the window is opened and drawn correctly, it gets corrupted when you drag it around the screen.
I'm convinced that this is a problem with my GCC setup rather than my code so I've just purchased a copy of Acorn C/C++ from ROOL.
[Edited by ColinWard at 09:07, 10/5/2011]
[Edited by ColinWard at 09:08, 10/5/2011] |
| |
[ Log in to reply ] |
| |
|
Andrew Rawnsley |
Message #117656, posted by arawnsley at 09:46, 10/5/2011, in reply to message #117653 |
R-Comp chap
Posts: 600
|
I don't program with OSlib, and I tend to use makefiles (one created by hand 15 years ago, suitably copied/modified for each subsequent project), but I suspect your syntax for GSS commandline may be wrong.
Most c compilers will output object files and need a separate link tool to link the objects together. The -l in your command line may trigger a link as well, but then your compiler command is mixing object files and c pre-compiled code.
There's Sourcery from Really Small Software Company available as a development environment that probably eases some of this (I'd imagine that compiling projects and linking becomes a button click).
I'd also repeat that Norcroft objected to your use of the single memblock, and wouldn't allow you to set your struct pointers to that block. You might want to try just allocating structure space separately, and then your code might well work (and do the task registration fix).
Also, (a cheeky) final point, you might want to consider trading your beagleboard in for an upgrade to an ARMini, as our machines come pre-designed for development/coding etc. We give you a good trade in (120ukp) for your xm against the full machine, and make all the mods to the board for you. |
| |
[ Log in to reply ] |
| |
|
Rob Kendrick |
Message #117657, posted by nunfetishist at 10:08, 10/5/2011, in reply to message #117654 |
 Today's phish is trout a la creme.
Posts: 525
|
What version of GCCSDK are you using? Didn't they change to ELF? I'd expect the error you are seeing if you tried to give it Acorn-style AOFs when it was expecting ELFs.
If you ever plan on doing C++, learning the GCC tools is valuable: Norcroft's C++ support is basically nil. |
| |
[ Log in to reply ] |
| |
|
Trevor Johnson |
Message #117658, posted by trevj at 10:34, 10/5/2011, in reply to message #117654 |
Member
Posts: 660
|
Let me then say I'm on the verge of giving up my foray into RISC OS - this is SO frustrating! [...] I've just purchased a copy of Acorn C/C++ from ROOL.
Hang in there! Can you get to a local user group to discuss/demonstrate this in person? |
| |
[ Log in to reply ] |
| |
|
Bryan Hogan |
Message #117659, posted by helpful at 10:50, 10/5/2011, in reply to message #117658 |
Member
Posts: 255
|
Hang in there! Can you get to a local user group to discuss/demonstrate this in person? Colin is a semi-regular ROUGOL attendee, so someone may be able to help next Monday.
In fact, ROUGOL are probably to "blame" for getting him into RISC OS and BeagleBoards  |
| |
[ Log in to reply ] |
| |
|
Bryan Hogan |
Message #117660, posted by helpful at 10:55, 10/5/2011, in reply to message #117659 |
Member
Posts: 255
|
... someone may be able to help next Monday. If someone would like to volunteer to do a "Getting started with GCC on RISC OS" and/or "WIMP programming in C" demo at ROUGOL that would be very helpful!
Please get in touch if you think you could do this. Contact details on the website:
http://rougol.jellybaby.net/contacts/index.html |
| |
[ Log in to reply ] |
| |
|
James Lampard |
Message #117664, posted by Lampi at 12:14, 10/5/2011, in reply to message #117656 |
Posts: 190
|
Most c compilers will output object files and need a separate link tool to link the objects together. The -l in your command line may trigger a link as well, but then your compiler command is mixing object files and c pre-compiled code.
1. GCC 'calls down' to the appropriate command required - it will call the c-compiler to compile c sources and will call drlink to link (unlike norcroft where you have to specify the correct command each time). So when linking with GCC, you do indeed use the GCC command.
2. It's standard practice for C Compilers to have a 1 stage compile and link command for a single source file too.
3. He's using an '-i' not a '-l' but shouldn't it be -IOSLib:
4. The syntax does look wrong to me though
Can you give more details of what you are doing Colin? |
| |
[ Log in to reply ] |
| |
|
Colin Ward |
Message #117668, posted by ColinWard at 13:57, 10/5/2011, in reply to message #117657 |
Member
Posts: 16
|
What version of GCCSDK are you using? Didn't they change to ELF? I'd expect the error you are seeing if you tried to give it Acorn-style AOFs when it was expecting ELFs.
If you ever plan on doing C++, learning the GCC tools is valuable: Norcroft's C++ support is basically nil. Hi Rob.
I'm using gcc 4.1.1, available from here:
http://www.riscos.info/index.php/GCCSDK
And yes, I think that the problem is that the .o file delivered with the OSLib library is in the old Acorn format while GCC expects ELF format. I suppose I should E-Mail the owner of the library to ask for this to get updated, or try and compile it myself if the source is available.
I'm now 99% convinced that my crashing program is due to some problem with GCC and/or my environment setup, given that others on this group have said that they could compile and run my code both with GCC and Acorn C/C++. I've just purchased a copy of Acorn C/C++ to try for myself (yes I'm that determined to figure it out!). Even if it's not too useful for C++ it should be a good learning tool for a RISC OS programming newbie. |
| |
[ Log in to reply ] |
| |
|
Colin Ward |
Message #117669, posted by ColinWard at 14:04, 10/5/2011, in reply to message #117664 |
Member
Posts: 16
|
Most c compilers will output object files and need a separate link tool to link the objects together. The -l in your command line may trigger a link as well, but then your compiler command is mixing object files and c pre-compiled code.
1. GCC 'calls down' to the appropriate command required - it will call the c-compiler to compile c sources and will call drlink to link (unlike norcroft where you have to specify the correct command each time). So when linking with GCC, you do indeed use the GCC command.
2. It's standard practice for C Compilers to have a 1 stage compile and link command for a single source file too.
3. He's using an '-i' not a '-l' but shouldn't it be -IOSLib:
4. The syntax does look wrong to me though
Can you give more details of what you are doing Colin?
I'm compiling a .c file and linking it with the oslib32.o glue code that comes with OSLib. I'm surprised that it's not a .a file which is why I was wondering if there was something different about RISC OS that I had missed (like maybe it treats a .o file as a .a file or something unusual). I'm using the following command line:
gcc -I oslib wimp2.c oslib/oslib32.o
After some discussion in this thread, I think that it's simply a case that the oslib32.o file is in Acorn's format and that GCC 4.1.1 expects it in ELF format. It's surprising that it's not been updated to be ELF already.
BTW, the -I oslib parameter is just so that it can find the .h file when compiling. It should probably be -I OSLib: as you say but I'm a complete beginner on RISC OS. I guess that -I OSLib: enables it to find the library headers no matter where they live? But for this to work, wouldn't you have to "run" the OSLib directory at startup so it registers itself?
Colin (who is learning to program RISC OS at the same time as learning to *use* it) |
| |
[ Log in to reply ] |
| |
|
Colin Ward |
Message #117670, posted by ColinWard at 14:06, 10/5/2011, in reply to message #117659 |
Member
Posts: 16
|
Hang in there! Can you get to a local user group to discuss/demonstrate this in person? Colin is a semi-regular ROUGOL attendee, so someone may be able to help next Monday.
In fact, ROUGOL are probably to "blame" for getting him into RISC OS and BeagleBoards
Yes, it is indeed all your and ROUGOL's fault Bryan! I'm glad that we have cleared that up. ;-)
BTW, I've ordered a CD-ROM of Acorn C/C++. If I have that by next Monday is it possible to install it on the RISC PC that is usually at the club meeting and from there onto my Beagleboard's USB stick? I won't be able to install it onto my Beagleboard given that it doesn't have a CD-ROM drive. |
| |
[ Log in to reply ] |
| |
|
Bryan Hogan |
Message #117672, posted by helpful at 15:16, 10/5/2011, in reply to message #117670 |
Member
Posts: 255
|
Yes, it is indeed all your and ROUGOL's fault Bryan! Sorry 
But think of all the fun and curries you would have missed out on!
... install it on the RISC PC that is usually at the club meeting and from there onto my Beagleboard's USB stick? We have never got the USB working on the RiscPC :-(
I will have my laptop with RPCemu, so we can use that.
I won't be able to install it onto my Beagleboard given that it doesn't have a CD-ROM drive. I wonder if ROOL have any plans to deal with that interesting gotcha? Maybe send out the tools on a memory card? |
| |
[ Log in to reply ] |
| |
|
Trevor Johnson |
Message #117675, posted by trevj at 17:42, 10/5/2011, in reply to message #117672 |
Member
Posts: 660
|
I won't be able to install it onto my Beagleboard given that it doesn't have a CD-ROM drive. I wonder if ROOL have any plans to deal with that interesting gotcha? Maybe send out the tools on a memory card?
I'm sure they do, but it's also the case that the installer (or perhaps just SparkFS within it) isn't currently ARMv7-safe. |
| |
[ Log in to reply ] |
| |
|
Steve Fryatt |
Message #117678, posted by stevef at 22:56, 10/5/2011, in reply to message #117668 |
Member
Posts: 18
|
I'm using gcc 4.1.1, available from here:
http://www.riscos.info/index.php/GCCSDK
And yes, I think that the problem is that the .o file delivered with the OSLib library is in the old Acorn format while GCC expects ELF format. Correct. Recent versions of GCC require the ELF binary format, while pre-built releases of OSLib haven't (yet) progressed beyond AOF.
I suppose I should E-Mail the owner of the library to ask for this to get updated, or try and compile it myself if the source is available. The source is available, from the link I gave you earlier! Failing that, the developers are helpful (and overlap with the people who look after the RISC OS GCC, so they might be able to help there too).
If you have access to a Linux box, ELF OSLib can be built easily from within the GCCSDK Autobuilder. That's how I do it, and I routinely use the result for building NetSurf, PrintPDF, CashBook and other stuff with GCC. I'd imagine that you can also do it on RISC OS, but it isn't something I've tried: TBH, your code was the first thing I've compiled natively on RISC OS for ages, because I use the GCCSDK for everything these days.
I'm now 99% convinced that my crashing program is due to some problem with GCC and/or my environment setup, given that others on this group have said that they could compile and run my code both with GCC and Acorn C/C++. I did point out earlier that you seemed to be doing some dodgy stuff with pointers in some of the Wimp_ calls. Maybe that works OK on older ARM/RISC OS combos but trips up on the Beagleboard setup? Could you stick your compiled binary up somewhere, so that we could see if it's happier on another processor/OS combination? |
| |
[ Log in to reply ] |
| |
|
Steve Fryatt |
Message #117679, posted by stevef at 23:06, 10/5/2011, in reply to message #117669 |
Member
Posts: 18
|
I'm compiling a .c file and linking it with the oslib32.o glue code that comes with OSLib. I'm surprised that it's not a .a file which is why I was wondering if there was something different about RISC OS that I had missed (like maybe it treats a .o file as a .a file or something unusual). No: as noted elsewhere, you've got the wrong format of library file for the version of GCC you're using.
I'm using the following command line:
gcc -I oslib wimp2.c oslib/oslib32.o
[...]
BTW, the -I oslib parameter is just so that it can find the .h file when compiling. It should probably be -I OSLib: as you say It should, or an absolute path -- it doesn't matter which. You'll also need an -Loslib.a where "oslib.a" is the full path to the ELF file.
But for this to work, wouldn't you have to "run" the OSLib directory at startup so it registers itself? Yes, or you roll it yourself somehow. Getting libraries to work on RISC OS is "fun" IME, whether you're using GCC or Norcroft. Most libraries are configured differently, and you'll probably end up modifying each of them into whatever standard format you prefer. |
| |
[ Log in to reply ] |
| |
|
Colin Ward |
Message #117727, posted by ColinWard at 08:41, 14/5/2011, in reply to message #117678 |
Member
Posts: 16
|
I did point out earlier that you seemed to be doing some dodgy stuff with pointers in some of the Wimp_ calls. Maybe that works OK on older ARM/RISC OS combos but trips up on the Beagleboard setup? Could you stick your compiled binary up somewhere, so that we could see if it's happier on another processor/OS combination? Hi Steve.
There is definitely some confusion about these so-called "blocks" and about whether you are supposed to use the same memory for different function calls. Examples I have seem intimate that you do but then your examples don't do that so I've got some things to learn there. But I can't see those warnings causing things to not work at all.
The good news it that my Acorn C/C++ came in the post last night and after adding a couple of casts for dodgy pointer assignment it works PERFECTLY on my RISC OS emulator! So next step is to try it on my Beagleboard (which is at work) and see how that goes. This is my original unmodified example by the way, with raw _swi() calls and given that this works with Acorn C/C++ it explains why I couldn't get it to work no matter how much I tweaked it - because there was nothing wrong with it!
So I'm half way there now but I have to figure out why it won't work with GCC as that will be my target compiler for porting my software from Amiga OS as it's written in C++.
Thanks to everyone for all the encouragement! |
| |
[ Log in to reply ] |
| |
|
Colin Ward |
Message #117728, posted by ColinWard at 09:09, 14/5/2011, in reply to message #117727 |
Member
Posts: 16
|
There is definitely some confusion about these so-called "blocks" and about whether you are supposed to use the same memory for different function calls. Examples I have seem intimate that you do but then your examples don't do that so I've got some things to learn there. But I can't see those warnings causing things to not work at all. Replying to myself...
Regarding the warnings in my original code, I just remember that I tried your converted code on GCC as well with no luck (using the OSLib headers but raw _swi() calls) so it's got to be some problem with GCC. I'm just about to head to work to gather some more clues now... |
| |
[ Log in to reply ] |
| |
|
Colin Ward |
Message #117729, posted by ColinWard at 11:47, 14/5/2011, in reply to message #117728 |
Member
Posts: 16
|
GOT IT!!!
My GCC build version runs fine if I run it by double clicking on its icon. If I run it from the command line as "a/out" then it crashes! Now going back to my "working" Acorn C/C++ compiled version it too only runs when double clicked!
I've never heard of an OS that works like that before... does anyone know why you can't run a program from the command line? At least my little test programs seemed ok. Is it just Wimp programs that won't run?
PS. I could swear that double clicking on the program's icon in the past didn't work but then I've tried so many things that I can't remember what I have and haven't done.
Mystery solved. On the RISC OS programming page we need to put in big letters for beginner engineers: "DON'T RUN YOUR PROGRAM FROM THE COMMAND LINE!" |
| |
[ Log in to reply ] |
| |
|
Martin Bazley |
Message #117730, posted by swirlythingy at 14:24, 14/5/2011, in reply to message #117729 |
Posts: 460
|
Well, I can think of a good reason... why on earth were you trying to launch a multitasking program from the command line?
I'm amazed it didn't conk out immediately with "Window Manager is in use", because that's absolutely what it's supposed to do. It sounds as if there is a bug there, but it's not what you were thinking of...
Running from the command line is immaterial, because a double-click simply issues the command "Filer_Run filename", which causes the Filer to first pass the filetype around any running programs to check if they want it (to which, in the case of an executable file, the answer should always be no), and if that fails, it issues the command "Run filename". The only difference is that it issues it from a multitasking environment, not the single-tasking command line, or the TaskWindow which pretends to be single-tasking. In both those circumstances, if the program run later attempts to call Wimp_Initialise, it should always fail. Whatever did you try to do?
FWIW, the only way to issue a command manually from a multitasking environment (one which has previously called Wimp_Initialise) that I am aware of is the Task Manager's "New task" submenu. |
| |
[ Log in to reply ] |
| |
|
James Lampard |
Message #117731, posted by Lampi at 15:01, 14/5/2011, in reply to message #117729 |
Posts: 190
|
I've never heard of an OS that works like that before... does anyone know why you can't run a program from the command line? What you think of as the command line is in fact a module called TaskWindow. This calls Wimp_Initialise to register itself as a wimp task and then reqularly calls Wimp_Poll to multi-task.
RISC OS is a cooperative multi-tasking system where only wimp tasks are supported. Only via something like TaskWindow can you multi-task ordinary programs within it.
As Martin points out running a program by double clicking on it is just as much part of the 'command line'.
The other possibility is that you are running your commands after pressing F12 in which case you are using another module called ShellCLI, which also calls Wimp_Initialise (but never calls Wimp_Poll) which will prevent you from running a wimp task directly within it.
At least my little test programs seemed ok. Is it just Wimp programs that won't run? Yes.
FWIW, the only way to issue a command manually from a multitasking environment (one which has previously called Wimp_Initialise) that I am aware of is the Task Manager's "New task" submenu. No, there is also the *WimpTask command and the Wimp_StartTask swi. |
| |
[ Log in to reply ] |
| |
|
Rob Kendrick |
Message #117732, posted by nunfetishist at 15:19, 14/5/2011, in reply to message #117730 |
Today's phish is trout a la creme.
Posts: 525
|
Well, I can think of a good reason... why on earth were you trying to launch a multitasking program from the command line? Probably because on every other OS I can think of it works Even on Mac OS 9, which didn't have a "command line" unless you had the developer tools installed. |
| |
[ Log in to reply ] |
| |
| Pages (2): 1
> >|
|
