Help with debug of ToolBox app
John Rickman (71) 622 posts |
For two weeks I have been learning how to use Acorn C/C++; reading It seemed sensible to start from one of the existing examples and The !MinApp res file is a bit busy – it contains 32 objects – so I thought However, after deleting ANY res object a build of MinApp results in For example I deleted the Alignment window object saved the res file, leaving Running the MkInstall file gave no obvious error messages. Is this an unresolved reference? I would be grateful for any help. |
Rick Murray (539) 13350 posts |
I don’t use the Toolbox, but I’ve had a quick look and can confirm that deleting something makes the iconbar icon vanish, while the application installs. By replacing the MainMenu entries with a blank ‘null’ menu, I can trim the Res file down to: FileInfo, FindRepl, GoTo, IbarMenu, IconBar, LineSpace, MainMenu, MainWindow, Options, OtherSize, ProgInfo, SaveAs, and Scale. Some are clearly ot necessary (Scale, LineSpace…) but something in the Res file needs these, and without their presence the Toolbox will fail to initialise (which is why there is no iconbar). In _kernel_oserror *ohcrap; Now change the toolbox registration to say this: ohcrap = toolbox_initialse (0, WimpVersion, &wimp_messages, &toolbox_events, "<MinApp$Dir>", &messages, &id_block, 0, 0, 0); if (ohcrap != NULL) { wimp_report_error(ohcrap, 0, "MinApp"); exit(0); } Then, upon hitting an initialisation failure, you will be told the usual “MinApp may have gone wrong. Click Continue to try to resume or Quit to stop MinApp.”, and if you click on the “Describe” button, you will see some gibberish like “Invalid Object Id (0×540349dc) (0×426779dc) (0×2).” which is a ridiculous and useless error but it will clue you in to the fact that the Toolbox subsystem failed to initialise. Whoever wrote that application, kindly rap yourself across the knuckles for failing to include basic rudimentary error trapping. Very very bad form for a tutorial/demonstration program! |
Rick Murray (539) 13350 posts |
BTW, thank you for reminding me why I don’t use the Toolbox. Let’s see…
|
Rick Murray (539) 13350 posts |
Okay, found it. I used ResTest on the “faulty” Res file, then looked in the log to see which objects it had successfully loaded (which seem to be loaded in a haphazard manner). It failed with the expected gibberish message, but the log indicated that Iconbar, MainMenu, and MainWindow had not been loaded. It isn’t going to be Iconbar. MainMenu was just a dummy entry now. This leaves us with MainWindow. After rummaging around in the properties, I found a list of Key shortcuts that were referring to the various objects that could not otherwise be deleted. I removed all of the shortcuts, then removed all of the now-orphaned objects that were not wanted. Now MinApp’s Res file contains: IbarMenu, Iconbar, MainMenu, MainWindow, Options, and finally ProgInfo. That’s the least you will need for the application to have an Options dialogue, the editor style window, and plonk itself on the iconbar and, you know, look like an app. I’ll stick to DeskLib thanks. More typing, but far easier to understand what’s going on. |
John Rickman (71) 622 posts |
Rick – Thanks for your replies. I have been well-underwhelmed with the experiences so far of developing desktop apps in C, but will persevere as the pain must be good for the soul. |
Rick Murray (539) 13350 posts |
Once you find a library you like, it can be simpler than using BASIC. One of the biggest benefits is the ability to used structures with named elements instead of the memory pokage typical in BASIC.
I believe that a “belief” must be something empowering, not something that must be suffered or endured.
You said you wrote software with BASIC using DrWimp, then Routines, then AppBasic. The only difference between this and C is that – generally – BASIC limits how you can use libraries. If it were possible to call in the code for all three at the same time, you would find the situation to be a gigantic mess not unlike C. C thrives on the idea of libraries. The C language itself is extremely basic and simple and doesn’t do much. It’s the many libraries that give it power. But, just because a dozen libraries exist does NOT mean you need to use them all. For BASIC, I use a heavily modified custom version of WimpEd, a little Wimp program creator that came off a cover disc a long long time ago. The library had bugs and was more aimed at RISC OS 2 than anything later, so it got “evolved”.
I notice you didn’t mention RISC_OSLib. You know, had the Acorn supplied library not been a steaming pile of elephant dung, maybe we’d have fewer libraries? Okay, let’s see (my opinions, others may disagree)…
A custom library? Don’t look so surprised, you in the back of the room, did you know that there are at least FOUR versions of DeskLib kicking around? The v2.30 original, the v3.20 “Desk” library which was a massive rewrite that utterly broke compatibility and was thus ignored by the majority, the current GCCSDK incarnations, and… uh… mine. ;-) The thing is, when I need a custom function, I tend to add it to my version of DeskLib so others can use it if they like. I don’t have much free time, but from time to time I do still update my build…
AOF is directly compatible with RISC OS. ELF is not. Unfortunately it seems current (?) and future versions of GCC are dropping support for AOF so it’s a one-or-the-other choice. I’m sticking with AOF as it is the original native format supported by the official toolchain. ELF offers various attributes like dynamic linking (a la Otter browser) but it sounds a little too much like introducing DLL Hell to RISC OS for my liking. ;-) At The End Of The Day When All Is Said And Done And The Fat Lady Sung About A T-shirt… both are capable compilers and toolchains and both can be used to create substantial pieces of software. The DDE can build RISC OS itself, GCC cannot. On the other hand GCC can build Otter, DDE cannot. My honest advice is – try them both. Stick with the one you like.
Wow. You’ve lived a sheltered life. There’s nothing, nothing, in any part of programming RISC OS that is anywhere near as bad as Brexit, and even that gigantic cock-up is borderline trivial compared to some of the weird crap that my mind comes up with. You remember the song that was the theme of Donnie Darko? “The dreams in which I’m dying are the best I’ve ever had”… I kinda know what he was talking about. And when I was working night shift a few years ago and seriously sleep deprived, every night was a nightmare of epic proportions. If I was better at remembering my dreams I could have been a billionaire off the movie rights… just so long as it’s all directed by Russell Mulcahy and not Michael-bloody-Bay. :-) |
Steve Pampling (1551) 7904 posts |
He’s been developing it more, according to the content of his talk at the ROUGOL meeting (I was in the general area and a visit seemed reasonable) |
John Rickman (71) 622 posts |
I used ResTest on the “faulty” Res file, then looked in the log to see which objects it had successfully loaded (which seem to be loaded in a haphazard manner). It failed with the expected gibberish message, but the log indicated that Iconbar, MainMenu, and MainWindow had not been loaded.
Thanks for pointing the way to debug the ToolBox stuff. I knew it had to be caused by a reference somewhere but did not know how to look for it.
After rummaging around in the properties, I found a list of Key shortcuts that were referring to the various objects that could not otherwise be deleted. ed.
I checked all the menu entries but did not think of the key shortcuts Now MinApp’s Res file contains: IbarMenu, Iconbar, MainMenu, MainWindow, Options, and finally ProgInfo. That’s the least you will need for the application to have an Options dialogue, the editor style window, and plonk itself on the iconbar and, you know, look like an app.
Thanks again. I now have a minimal app and can start working on the logic for a RISC OS Guitar tuner! (I know there are better ways of doing it. There must be 50 or so tuners on Android already) |
Andrew Rawnsley (492) 1391 posts |
Library preference tends to end up with “what you’ve had most experience writing programs with” feeling the most comfortable, and unless something offers dramatic improvements (and few downsides), it is likely to remain so. I would tend to caution new users when it comes to Toolbox, because whilst it is great for rapidly building user interfaces and automating much of the “grunt work” of desktop apps, you may well hit its limitations and find that hooking in more elaborate/traditional wimp code is more painful than it needs to be. One big problem with Toolbox is limited source modification. If you encounter bugs/problems or other things that would be easily resolved with source changes, you’d need those changes “upstreamed” into the master ROOL copies, and can’t change things on a “per app” basis, as the toolbox modules are shared components. I appreciate the point that a library should be entirely generic and removed from the needs of the specific application, but the more elaborate the library, and the more “high level” it becomes, the more likely you are to need to get your hands dirty if you step outside the author’s vision. For me, I grew up with RISC_OSLib and it was introduced to me by a couple of Acorn guys. I had its source from day one, and am really familiar with it. I find the code (for the most part) quite readable, and it has documentation (inc printed) which was/is handy. I know it has its detractors, but it is “close enough to the metal” that it is easy to code “around” it if needed, but only rarely have I needed to fix bugs or otherwise mess with it. Conversely, I hit the buffers with Toolbox difficulties the first time I tried to use it seriously. Now, I wouldn’t say that someone should go for that library necessarily – it is very dated – but there are pros and cons for all of them. Incidentally, one that I had real trouble with was DeskLib when updating old apps, as newer DeskLib builds seem rather incompatible with older ones. If you choose that library, make sure to pick a version that will be maintained, otherwise you could have headaches when new hardware comes along. That’s another point to mention. If you do pick a 3rd party library, for goodness sake choose one with source code available (and keep a copy with your software/build environment), so that you can re-compile it for newer hardware. One advantage of RISC_OSLib and Toolbox is that as core OS libraries, compatible versions should always be easily available here. |
Steve Fryatt (216) 2040 posts |
As Rick points out, this makes no sense. You’ve just listed a set of incompatible libraries for BASIC and seem happy that they all exist, then complain that there’s a similar choice for C.
Use AOF. GCC generates ELF intermediary files, compared to Norcroft’s ALF, but the end result will be AOF in all cases. That’s true of even the current versions of GCC as far as I’m aware – at least on the crosscompiling side, where I’d almost expect AOF to be less supported.
Use whichever you like the most. I don’t get on with Norcroft much; I’m also aware that this is something of a niche viewpoint… So, which Library? As Rick and Andrew say, it’s a personal choice. Like Rick, I’d also caution avoiding RISC_OSLib, as it’s interesting… Which leaves: OSLib isn’t a library as such, but a type safe set of veneers around every RISC OS SWI. I can’t stress enough how much of a good idea it is to use it, whichever other library you sit on top. Some libraries make this hard to do, which might influence your choice of how to proceed… The Toolbox was Acorn’s attempt at producing an event-driven system. I never grew to like it and, as Andrew says, it can be limiting as soon as you move beyond what it can do easily. TBoxLib and OSLib don’t get on well, as they share similar function names, but since TBoxLib is largely a way to call the Toolbox SWIs from C, I’d suggest using the Toolbox via OSLib if you wish to go down the Toolbox route. Did I mention that using OSLib is a really good idea? If you don’t wish to use the Toolbox, there’s the “old fashioned” way of doing things using Templates and another library. This is what I do, and what Rick and Andrew also seem to be describing. The other libraries that you list are all alternatives to each other using Templates, and all alternatives to the Toolbox. DeskLib is an early library that provides an event-driven structure and plenty of useful routines as an alternative to RISC_OSLib. ROVLib is Jason Tribbeck’s alternative to Desklib which provides an event-driven structure and plenty of useful routines as an alternative to RISC_OSLib. SFLib is my alternative to Desklib which provides… etc. It does have the advantage (in my opinion, at least) of being written using OSLib, and therefore coexisting nicely. I’m also a little biased. All three libraries effectively give you a Toolbox-like environment whilst not using the Toolbox. Which you pick is a personal decision, and as Andrew says, will come down to availability of source code, availability of support, the licences, and which one(s) “click” with you. I wrote SFLib because none of the others clicked with me, and I expand it whenever I realise that I’m just about to write the same bit of code for more than one application. But, whatever you do, use a library of some sort to handle the grunt stuff. C can be a lot more event-based than BASIC which, coupled with its memory handling and ease of modularisation1, are huge advantages. It’s a bit of a mental shift to make, but once you’ve done it, you won’t look back… 1 Relative ease, that is. Writing anything for RISC OS suddenly looks more than a bit primitive once you’ve worked in a modern language for another platform. |
Jeffrey Lee (213) 6044 posts |
There seems to be a bit of confusion here.
AIF is the only format which is natively supported by every RISC OS machine. AOF and ALF cannot be executed directly, they need to be translated to AIF (or a module) first. If you have an executable ELF, you will need to have the SOManager module loaded in order to be able to run it, in which case it can be *Run just like an Absolute file. If you have a staticly-linked executable ELF, you can use AIUI modern versions of GCC (GCC 4 and later) are fully ELF-based, apart from (a) the aforementioned elf2aif tool which can be used to convert staticly-linked ELF files to AIF, and (b) |
Frank de Bruijn (160) 224 posts |
That’s a new one to me. I always thought ELF was Executable and Linking Format. |
Jeffrey Lee (213) 6044 posts |
You’re right. I’m not sure I’ve ever looked up the name before! |
John Rickman (71) 622 posts |
As Rick points out, this makes no sense. You’ve just listed a set of incompatible libraries for BASIC and seem happy that they all exist, then complain that there’s a similar choice for C.
The lack of sense is clearly my fault for not explaining my experience of developing in BASIC compared to trying to develop in C. A user of DRWimp, or AppBasic is scarcely aware that he or she is using a Library and is certainly not confronted by having to choose one, or choosing between libraries, or having to set up variable to point to them. Install AppBasic, run it, drag a skeleton application to where you want, change its name and icon, and insert your own code, and there you have it. It took about half a day for me to feel at home within the AppBasic development environment. Had it not been for the calamitous cock up with the ROOL and ROL ToolBox versions I would not have thought of abandoning it. |
Steffen Huber (91) 1945 posts |
I would recommend not using the Toolbox. The idea to provide a library in form of modules is inherently broken in a RISC OS context, since you cannot have multiple versions of the same module running at the same time. Also, while the Toolbox is fine in theory, it adds only very little abstraction over plain old WIMP. Most Toolbox stuff can be easily redone at a WIMP level with minimal effort. The only exception is probably Rik Griffin’s stuff (the tree and the tab thing). The reliance on ResEd and its complications to get extended to support 3rd party add-ons usually leads to the non-availability of 3rd party add-ons. Which again shows that part of the Toolbox concept is inherently broken. My recommendation: use OSLib. Additionally, use whatever lib you try and find usable and which has source available and which has the right licence. Establish a standard way to build your applications with both Norcroft and GCC. Find out if developing on Linux is on option for you – GCCSDK, IDEs, version control. |
Rick Murray (539) 13350 posts |
That’s because you came to the game a little later. Us grey haired gits remember when we wrote our own Wimp libraries and built windows up as data blocks because FormEd was so bleedin’ awful. There have been multiple attempts at a cohesive library for BASIC. And like C, you can’t jump ship because they aren’t compatible with each other. The difference is that doing such a thing (lots of libraries) is unusual in BASIC, but pretty commonplace in C – because as I said earlier, in C pretty much everything is a library function.
? Run !DeskLib, it puts a filer window in the upper right with access to all the header files. Also it sets up paths so #include “DeskLib:Something.h” just works… I cheat. I have an obey file in Boot that runs the DDE, runs DeskLib, runs Zap… So every boot, all that stuff is ready to rock and roll. Seriously, I can drop a source from a project into Zap, press ShCtrlC and it’ll just build.
I started writing something like that for DeskLib. It can spit out some boilerplate for the application, but that’s as far as I ever got because, well, that’s about as much as I needed. It gives me an app framework so I can skip the boring initial bit.
It took me about three years to get used to writing code in C, coming from BASIC and assembler. Most of that was getting my head around C and I’ll admit I wasn’t trying too hard. For a while I’d even “prototype” applications in BASIC to then rewrite in C. The biggest contributor? DeskLib. No, really. I had C v4 and I must have read that book on the Acorn library a bunch of times. It seemed to offer lots of promise but when you got down to actually trying it, it made no bloody sense at all. Things were haphazardly named and the library was constructed terribly in that using one function from a code block pulls in the entire block which is horrid for programs intended to run on 1MB machines. Did I mention the names of things (structure elements) were gibberish and inconsistent?
Nobody can state this loudly enough. It wasn’t a library, but I discovered that I simply couldn’t use Zap on my shiny new Pi2, which I found extremely odd given the Pi2 we like two years old. This, for me, was a show stopper. StrongEd isn’t Zap, though it gets better every new release so maybe some day soon…? Anyway, since the Zap source was floating around, I got up off my ass (backside or donkey, it’s all the same to me) and did something about it. Without the source, Zap would have died a long time ago. You know, like <insert favourite relic of the 26 bit era>. ;-) |
Clive Semmens (2335) 3110 posts |
Something I couldn’t have done, on or off my ass. And I can’t repeat often enough how hugely grateful I am. |