ReportPlus is a freeware ReAction-based utility with lots of functions and commodities, this program is developed by James Jacobs, betatested and compiled on OS4 by me
The new 6.67 version released fix quite all the remaining bugs discovered during the OS4 porting process so now it should be quite stable and complete on both (68k and PPC) architectures
ReportPlus still needs a little work. I copied the sources out of the ReportPlus directory to see how it would compile. When I started my compiled ReportPlus without the images available it crashed my system which required a system reset. It should check for valid images before opening and notify the user of the image problem. It's good to get some Reaction example for a larger program like ReportPlus.
Mmm sorry for the stupid question but are you sure about this specific problem?
I compiled this proggy many time already and without any image (only the source folder) but i never seen any crash or similar
Aniway the source is opensource/freeware so if you like to propose or do some changes/fix feel free to do it as you like, just send back to us your modifications (i'm sure they can be merged eventually)
@samo79 I tried the ReportPlus binary that was in your archive and without the image directory is just shows a requester stating "Can't create Reaction images!" When I compile the sources and run ReportPlus without the image directory I get the same requester but I get a Grim Reaper after I cancel the requester. Unless someone else can compile the sources and comfirm my crash, I guess that we will have to assume the problem is with my system or SDK.
The binary included in the archive is much smaller than the binary I get when I compile the sources ( 597,344 vs 896,272). Are you using the latest publicly available SDK from Hyperion's WEB site? By the way I'm using a SAM Flex 800 with OS4.1u2.
I tried the ReportPlus binary that was in your archive and without the image directory is just shows a requester stating "Can't create Reaction images!"
Yes this is quite normal i presume, infact here is the same. For start ReportPlus you need all the GUI elements (putting the bin into the ReportPlus main dir with images and so on), the error message in requester just try to tell users about that
Quote:
When I compile the sources and run ReportPlus without the image directory I get the same requester but I get a Grim Reaper after I cancel the requester. Unless someone else can compile the sources and comfirm my crash, I guess that we will have to assume the problem is with my system or SDK.
Mmm this is a bit strange, almost here it never crashed after this requester message, just in case please send back the crashlog you have !
Quote:
The binary included in the archive is much smaller than the binary I get when I compile the sources ( 597,344 vs 896,272)
You are a developer so for sure here your experience and knowledge are far better than me: maybe (just maybe) isn't related at all but did you include the battmem.h file included in source to --> "SDK/include/include_h/inline4/" ?
Latest SDK missed it completely and even if ReportPlus for OS4 (native version) doesn't use it anymore at the end this file might be needed elsewhere as deps (?)
Aniway, still i really can't understand this difference in our bin size, i think here the main author of ReportPlus can enlight us a bit more
Quote:
Are you using the latest publicly available SDK from Hyperion's WEB site? By the way I'm using a SAM Flex 800 with OS4.1u2.
Yes i'm using the latest pubblic SDK with GCC 4.2.4 and my system is the same of yours (Sam Flex 800 with AmigaOS 4.1 Update 2)
Edited by samo79 on 2011/8/13 5:31:28 Edited by samo79 on 2011/8/13 5:34:42
I tested the debug version of ReportPlus after compiling it and Grim Reaper reports the failure in the sb_clearlist() function. The image loading fails before SpeedBarList is initialized with NewList() but the cleanexit() function calls the sb_clearlist() function to clean up the uninitialized SpeedBarList. That might be one of those things that accidently works sometimes and fails at other times (especially on OS4). After examining the rp.c code, I'm inclined to keep it for the Reaction example code but not likely to use the program. When there is an error, the program notifies the user and calls a cleanup function which uses "exit()" to end the program. Maybe I'm wrong but I don't think that exiting from nested functions (especially using -lauto starup) is a good idea on OS4 and I'm not inclined to spend any more time on ReportPlus. Maybe someone with more programming expertise would like to examine the code and comment further.
Maybe I'm wrong but I don't think that exiting from nested functions (especially using -lauto starup) is a good idea on OS4
There no reason why calling exit should be a bad thing, not even with -lauto (the cleanup code for the libauto stuff will be excuted by the 'destructors' invoked by exit())
In this case the code calls exit via a higher level cleanupexit() command which, closes all the libraries etc. The only thing it appears to miss is potemtial passing an unitilised list to the sb_cleanup() function as you commented yourself.
I'm wondering why it's built with libauto though when all the classes and libraries seem to opened 'manually' anyway.
If you are using it as an example of reasction coding you should bare in mind that under OS$ the OpenLibray / Gret Inetface appraoch to gettingthe class is now depricated in favour of the OpenClass() function. The reaction Macros are also depricated.
I've looked at the sb_clearlist() function, and while I can't see anything that would cause a crash right away (as Xenic reports), you definitely miss a Remove() here. Also, if you compile the source for OS4, you should avoid accessing the list structure directly. Change you code to this:
>The image loading fails before SpeedBarList is initialized with NewList() but the cleanexit() function calls the sb_clearlist() function to clean up the uninitialized SpeedBarList.
This bug was fixed in V6.67. What version are you using?
@trixie:
>you definitely miss a Remove() here.
It's not necessary since the entire list is getting freed and there is no possibility of failure during the operation. It's the same way it is done in the RKM examples.
@All:
There is a known bug in V6.67 when quitting via the Esc key, due to it doing so from a hook function. This has been fixed for V6.68 which will be released soon.
@broadblues Maybe I'm confusing the obsolete AmigaDOS Exit() with C exit(). I probably have too many old programming references that discourage the use of things like goto, exit(), and global variables. However, it certainly looks a lot easier to use global variables and goto a cleanup routine that calls exit(). Setting error codes and returning back to main() from nested functions while cleaning up on the way is a real pain.
As far as deprecated methods go; When the use of such methods is removed from the SDK documents and examples, I'll change my use of them. For example, Trixie's Recommended Practice blog at OS4Coding discourages the use of AutoInit (-lauto) but the OS4 Migration Guide states "The preferred method for initialization of system libraries is the usage of the libauto link library". I'm not saying Trixie is wrong but the current state of OS4 development documentation and examples is very confusing. As a result, I'm sticking with the official documentation and examples in the SDK.
@trixie Boy have I gotten myself into a mess by commenting on ReportPlus. I've discovered that I unarcived the newly released ReportPlus to the wrong location and was compiling and examining the wrong sources. When I wanted to test the included binary for comparison, I copied it from the new archive with Dopus4. I just compiled the new sources and it doesn't crash if the images are unavailable and the size of the binary is close to the size of the one included in the archive.
I must apologize to everyone for my blunders and hope I can avoid this type of mixup in the future. Hopefully, the resulting coding suggestions by others will be of some benefit in the end.
@Minuous You're right, I've found a bug that you have already fixed because of stupid mistakes on my part. Sorry about the mixup. Things like this happen a lot when you get to be my age. Broadblues has also pointed out that I'm wrong about the use of "exit()" so I'll have to apologize for that criticism too.
It's not necessary since the entire list is getting freed and there is no possibility of failure during the operation. It's the same way it is done in the RKM examples.
Are you sure it was in the RKM? The ROM Kernel Manual predates ReAction so freeing RA gadget lists couldn't possibly have been covered there. If you mean "SDK examples" then yes, there's a mistake there, although not a fatal one in this particular case (NewList() sets the list pointers to correct values and therefore does what Remove() would have done). Rigo is already after it and the examples will be changed appropriately in the next SDK.
Bottom line: ReAction gadget list nodes should be Remove()d before they are freed. This is better and safer practice than relying on NewList().
For example, Trixie's Recommended Practice blog at OS4Coding discourages the use of AutoInit (-lauto)
The information in my tutorial must be read in full context. You should not - in fact, cannot - use libauto if you want to open the classes via OpenClass(), ie. the way that is preferred under OS4 (and described in the tutorial). It is because libauto uses OpenLibrary() to open classes, instead of OpenClass().
You can use libauto if you want to open ReAction classes the original way, that is, using the macros or the public class ID. But you lose certain advantages, namely:
- speed (the OpenClass() method creates the classes faster); - version control (libauto opens whatever is found in the system and does not allow you to specify a minimum class version).
Quote:
the OS4 Migration Guide states "The preferred method for initialization of system libraries is the usage of the libauto link library".
This is IMHO nonsense and should be changed in the Guide.
I see that Trixie answered pretty much as I started to reply, so I won't repeat him, however, my main posint about libauto is that Minuos' code is allready opening libraries 'manually' ie not using libauto, so libouto shouldn't be included on the link line (it's probably harmless but depending on how things have been declared libraries might get opened twice, and at the least it's extra unneeded code)
If removing it results in a unopened library or missing symbol then for consistency wth the writen code that should be added to the existing library opening code.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
