OS4 DepotLogo by Nickman 
(anonymous IP: 18.191.165.149,2258) 
 HomeRecentStatsSearchSubmitUploadsMirrorsContactInfoDisclaimerConfigAdmin
 Menu

 Features
   Crashlogs
   Bug tracker
   Locale browser
 

 Categories

   o Audio (343)
   o Datatype (51)
   o Demo (203)
   o Development (602)
   o Document (24)
   o Driver (97)
   o Emulation (149)
   o Game (1011)
   o Graphics (500)
   o Library (118)
   o Network (234)
   o Office (66)
   o Utility (932)
   o Video (69)

Total files: 4399

Full index file
Recent index file

 Links

  Amigans.net
  OpenAmiga
  Aminet
  IntuitionBase


Support the site


 File comments for:  Development » Example » libraryhandling.lha

Libraryhandling

Description: The tedious job of handling libraries simplified
Download: libraryhandling.lha
Version: 2
Date: 04 Dec 2011
Category: development/example
FileID: 6746
RSS Feed url: https://eu.os4depot.net/modules/comments/rssfeed.php?file=development/example/libraryhandling.lha

[Back to readme page]   [Add Comment]   [Refresh page]

Comment by: whose (2.215.105.16)At: 05 Nov 2011, 16:43File version: 1
Hehe, nice, Im looking forward to the improved documentation! :)

Well, maybe I expressed my stance a bit too unclear... I dont like to give the compiler more work than needed, especially the (potentially slow) macro preprocessor. So a bit more fine-grained control over Library opening using your way would be a nice goodie. And it wouldnt need the inclusion of the protos anymore (which actually are of use for auto open feature only).

I see your point, and it will help those used to the "proto" way of opening libraries, definetly. Maybe I should modify it myself and make up a GUI driven resource editor then ;)

Anyway, keep up your nice work and I look forward to anything new that comes! :)
 
 
Comment by: OldFart (145.53.166.27)At: 05 Nov 2011, 15:35File version: 1
You absolutely do not need to modify the library list! One list goes for ALL your projects. If there becomes a new library available over time, be it an OS component or a third-parties, fire up your preferred editor, make the appropriate additional lines to the file and be done with it for the rest of your life. The proprocessor will take care which library gets opened by checking for the PROTO_xxx_H definition. It's that that makes it so simple.

The ReAction counterpart is 'on its way' and of course utilises what you call the "new way of opening classes". It would be counterproductive to do otherwise. Along with this comes a headerfile with ReAction macro's, making for much easier, and more consistent to boot, GUI building. Having said that, I'm currently trying to work around a caveat I encountered, which I like to get solved in an elegant way.

I'll take your remark to heed and will provide a (much, much ;-)) better set of documentation.

For the matter of library handling, though, I'm thinking of releasing an addendum, making things more clear and of course a nice piece of documentation.
 
 
Comment by: OldFart (145.53.166.27)At: 05 Nov 2011, 15:35File version: 1
You absolutely do not need to modify the library list! One list goes for ALL your projects. If there becomes a new library available over time, be it an OS component or a third-parties, fire up your preferred editor, make the appropriate additional lines to the file and be done with it for the rest of your life. The proprocessor will take care which library gets opened by checking for the PROTO_xxx_H definition. It's that that makes it so simple.

The ReAction counterpart is 'on its way' and of course utilises what you call the "new way of opening classes". It would be counterproductive to do otherwise. Along with this comes a headerfile with ReAction macro's, making for much easier, and more consistent to boot, GUI building. Having said that, I'm currently trying to work around a caveat I encountered, which I like to get solved in an elegant way.

I'll take your remark to heed and will provide a (much, much ;-)) better set of documentation.

For the matter of library handling, though, I'm thinking of releasing an addendum, making things more clear and of course a nice piece of documentation.
 
 
Comment by: whose (2.215.105.16)At: 05 Nov 2011, 14:24File version: 1
Hehe, yeah, I tried and it works nonetheless.

Well, Do you think about making up some helper tools to create the Library list? Ok, its not that hard work to edit all this by hand, but I think it would be a nice goodie for future IDEs (like e.g Codebench)

ReAction would be nice, too. Do you count in the "new way of opening classes" into this?
 
 
Comment by: OldFart (145.53.166.27)At: 04 Nov 2011, 22:33File version: 1
Thank you for your comment!

I must say, however, that for a yet undiscovered reason, something went a bit wrong. The file Main_00.c is far to complex, but nonetheless functioning. I had prepared a much simpeler one, but somehow things got mixed up and I ended up releasing this 'wrong' archive. I just discovered this fact this afternoon.

On the other hand, currently I'm prepairing a simmilar setup for ReAction-classes and stuff.
 
 
Comment by: whose (46.115.22.188)At: 04 Nov 2011, 18:44File version: 1
Nice Stuff! Although it really would need a bit more documentation, so that beginners could understand what youre doing there. INFO macros alone are hard to find, and how should beginners learn how you do the library opening/closing if they even dont find simple function entry macro implementation code? ;)

Besides that this stuff screams for automatic creation, so its definetly nice work :)
 
 

Copyright © 2004-2024 by Björn Hagström All Rights Reserved