Realy, then I assume that you have never used !WinEd?[/quote]Even then, for creating GUI applications *none* of these tools is as easy to use as something like QtCreator. Or Lazarus. Or...
I can understand this. Thank you for taking the time to use RISC OS, I feel now that the user base is once again increasing that many of the things that are wanted by many and not yet available will finaly begin to get filled in.dr_d_gee wrote:Like many others I would guess, while I'd heard of RISC OS before I'd never had such a machine—when they were new they were too expensive and, later on, it was obvious that RISC OS was in a state of terminal decline (or so it seemed, until the Pi came along, and gave it another chance).
!WinEd is one of the better known Templte Editors for creating Template files for easily creating Windows and there Icons. In RISC OS the term Icon is used to describe Buttons, Text Feilds, Static Graphics, etc so the usefulness of a Template Editor such as !WinEd or !TemplEd is very helpful. I do not know if any one still uses !TemplED or if it will run on the RPi, though for WinEd see:So I've never heard of !WinEd, whatever it is—and Google doesn't turn up anything relevant either. Linux can be inefficient—maybe Wayland (replacing X) may help, though probably not. Linux and most of its applications have got increasingly bloated; while it is still more efficient than Windows, it used to run on machines with 64MB of memory; now, on the Pi, it's inclined to struggle at times.
Yes this is true with most other OSes. As you are new to RISC OS I can understand your view on this. Though I believe that for most of us that have been using RISC OS for some time and are accustomed to the drag and drop (definitely for me) implementations, it is vey intuitive and much more productive than a modern IDE, so there has not been any need for this.But IDEs can be a time-saver, even if they are far from perfect (see Charles Petzold's article "Does Visual Studio rot the mind?" for some particulars of that tool—although some of these features are a VS speciality, as it were): http://www.charlespetzold.com/etc/doesv ... emind.html
Agreed, I really thought RISC OS was destined to a death of a 1,000 cuts - but it now does seem to be bouncing backdr_d_gee wrote: Like many others I would guess, while I'd heard of RISC OS before I'd never had such a machine—when they were new they were too expensive and, later on, it was obvious that RISC OS was in a state of terminal decline (or so it seemed, until the Pi came along, and gave it another chance).
Which is a real pity, I could always rely on (in the past) being able to put Linux onto a box that wasn't up to the latest Windows and have it doing "something", not now though which is a real pity.dr_d_gee wrote: Linux and most of its applications have got increasingly bloated; while it is still more efficient than Windows, it used to run on machines with 64MB of memory; now, on the Pi, it's inclined to struggle at times.
Yes IDEs definitely save time - and saved time allows people to get more stuff done.dr_d_gee wrote: But IDEs can be a time-saver, even if they are far from perfect (see Charles Petzold's article "Does Visual Studio rot the mind?" for some particulars of that tool—although some of these features are a VS speciality, as it were): http://www.charlespetzold.com/etc/doesv ... emind.html
That's true, but Raspberry Pi allows RISC OS to reach a larger audience.dr_d_gee wrote: The fact is that RISC OS needs to attract developers, and that's difficult these days
That's good news Bruce, if there is extensive (and current) information on programming RISC OS available this may encourage former developers to return and we may even see new ones join.MonitorMan wrote:Raspberry Pi RISC OS System Programming Book
Thought it might be beneficial at this point to mention I am currently working on a my next book in the “Hands On Guide” series, provisionally titled, “Raspberry Pi RISC OS System Programming.”
While the latter is important, as people may start joining from "outside" the traditional RISC OS developer community, it may be better to start first with how it's done now (32bit style) and maybe in a separate "boxed off" section then show how it was done in the 26bit variants (at least then previous developers will have the information to update their code - without presenting new developers with it upfront when it may/will have little relevance to them)?MonitorMan wrote:To a degree – as much as I can research – this will include additional material that has been updated since the PRMs (filing systems for instance). It will also show how to deal with programming issues that have changed significantly the advent of a full 32-bit ARM and CPSR, interfacing etc.
May be no harm sounding out people over at ROOL (and on their forum too) as they're actively involved in developing the OS and may be have information us mere mortals don't have access toMonitorMan wrote:I would be keen to get feedback from forumites about what people would like to see in the book. I would also been keen to include for any new material that users might be able to contribute. No point in doing the research twice!
Probably best to start a new thread at this point and then it'll give us all a better idea of the direction your book is going in - and also give you valuable feedback.MonitorMan wrote:What does everyone think? If there is interest then perhaps we can start a new “book thread” and I can include an active contents list regarding what is in and out?
There's no real need to extend an editor for that, just use StrongHelp. Most modes in Zap/StrongED already provide help for SWIs, just place the cursor in the SWI name and press c-H (Zap) or F1 (StrongED). This will bring up a StrongHelp page describing the SWI, assuming the right manuals are installed.DavidS wrote:I can understand extending a Text Editor to provide syntax based help on the lnguage beng used and the SWIs, OSBytes, OSWords, etc in order to provide some extra aid in developing aplications
A compiler (or any other tool that uses throwback) will only throw those things that can be led back to a filename + linenumber. Anything else would be useless.timrowledge wrote:A couple of fairly trivial suggestions, just for starters.
a) the compiler puts out a lot of text and uses throwback - but *doesn't damn well throw it all*.
b) the text output window is not cleared or automatically removed when you do another compile, so you too easily get cluttered up
Well, if you need any help getting StrongED stuff to work then by all means ask.timrowledge wrote:I'm aware that StrongEd has some stuff that goes some way towards this but I've never yet made it work. And not everyone likes StrongEd (I know, weird, huh).
I'd very much like to re-iterate Steve's point. Using the Toolbox with AppBasic/Basalt is probably the quickest way to create a user interface and allows you to focus on the business end of your application. StrongED even provides autocompletion for AppBasic calls.Steve Drain wrote:Application development can be quick and easy with the Toolbox.
Just who is this General Protection Error and why is he reading my disk?General protection errors by the cartload
There are StrongHelp manuals that are similar to the PRMs that describe the APIs. They don't contain the background information that is in the PRMs, but they're a great, and quick, reference once you know the background stuff. See my earlier reply in this thread on how to use them from Zap/StrongED.Markodius wrote:Are there Stronghelp compatible versions of the PRM's?