Re: [fpc-devel] About modeswitch objectivec2
On 21 Jun 2010, at 01:21, Leonardo M. Ramé wrote: I often read the svn log of the trunk version, and today I noted that a mode called "objectivec2" was added. What's the objective of this addition? http://wiki.freepascal.org/FPC_PasCocoa Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OpenSSL bindings improvement
Hi 2010/6/2 Felipe Monteiro de Carvalho : > Hello, > > I need some functions of OpenSSL which aren't in > fpctrunk/packages/openssl/src/OpenSSL.pas > > So I am adding them and I will commit after I test. I just start adding RSA parts and making it Delphi compatible. What about your porgress ? Best regards. -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Rather large flaw in TJSONConfig component
Hi, Attached is a patch which extents the jsonconf test suite. The new test highlights a rather big flaw in the workings of the TJSONConfig component. This issue might even apply to TXMLConfig component too - I haven't looked yet. This came about in the discussion in the Lazarus mailing list about Lazarus IDE storing application settings in XML files. I investigated the idea of replacing my usage of INI files for storing application settings with JSON files (TJSONConfig) instead. In each of my applications, I store all GUI Form state (position, size, etc) all in one "application settings" file - each form has it's own XXXFormState section. In the test TestConcurrency I simulate two forms being opened - each form contains a TJSONConfig component. When I close one form it writes the state information. When I close the second form, it overwrites the whole JSON file, wiping out the first form's information completely. This is rather dangerous behaviour! I see 3 solutions here: 1) Use a Singleton with TJSONConfig so we only have one instance of TJSONConfig per application. 2) Extend TJSONConfig so that it is more intelligent when writing to a file, and only writes the path information it modified or created. 3) When using one TJSONConfig per form, force the developer to use a different .json file for each form. Any comments or alternative solutions? I know XMLConfig and JSONConfig are not documented yet, but if nothing is going to be done about this concurrency issue I highlighted, then the documentation must clearly state the dangerous behaviour of these components. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ jsonconftest.patch Description: application/mbox ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
On 21 June 2010 14:20, Graeme Geldenhuys wrote: > Hi, > > Attached is a patch which extents the jsonconf test suite. The new test > highlights a rather big flaw in the workings of the TJSONConfig component. > This issue might even apply to TXMLConfig component too - I haven't looked > yet. > > This came about in the discussion in the Lazarus mailing list about Lazarus > IDE storing application settings in XML files. I investigated the idea of > replacing my usage of INI files for storing application settings with JSON > files (TJSONConfig) instead. In each of my applications, I store all GUI > Form state (position, size, etc) all in one "application settings" file - > each form has it's own XXXFormState section. > > In the test TestConcurrency I simulate two forms being opened - each form > contains a TJSONConfig component. When I close one form it writes the state > information. When I close the second form, it overwrites the whole JSON > file, wiping out the first form's information completely. This is rather > dangerous behaviour! > > I see 3 solutions here: > > 1) Use a Singleton with TJSONConfig so we only have one instance of > TJSONConfig per application. > 2) Extend TJSONConfig so that it is more intelligent when writing to > a file, and only writes the path information it modified or created. > 3) When using one TJSONConfig per form, force the developer to use > a different .json file for each form. > > > Any comments or alternative solutions? I know XMLConfig and JSONConfig are > not documented yet, but if nothing is going to be done about this > concurrency issue I highlighted, then the documentation must clearly state > the dangerous behaviour of these components. Seriously, would you try the same thing with a file? Open it in two different places and try and write to it from both places and see what happens. Programs that want to write to the same json file from different classes need to handle this properly, just like they would have to when using files. The behaviour is completely logical, imho. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
On Mon, 21 Jun 2010 15:20:09 +0200 Graeme Geldenhuys wrote: > Hi, > > Attached is a patch which extents the jsonconf test suite. The new test > highlights a rather big flaw in the workings of the TJSONConfig component. > This issue might even apply to TXMLConfig component too - I haven't looked > yet. TXMLConfig reads by default the old config. You can switch this off to start with a clean config. Unless you use the same paths, no value is lost. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
Op 2010-06-21 15:34, Henry Vermaak het geskryf: > > Seriously, would you try the same thing with a file? Seriously, you would want to tell developers in todays times that they can't concurrently access a file? > Programs that want to write to the same json file from > different classes need to handle this properly, just like they would > have to when using files. Unfortunately TJSONConfig and TXMLConfig encapsulates the file handling - it's not available to the developer to change. So the file handling fix needs to occur in these components themselves. Lazarus IDE even makes the TXMLConfig component available to developers on the System component palette - ready to be dropped on any form. All without the warning of potential data loss (even with StartEmpty = False)! Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
[...Sorry, I think my first message's attachment was too big. This one is smaller...] On 21/06/2010, Mattias Gaertner wrote: > > TXMLConfig reads by default the old config. > Unless you use the same paths, no value is lost. Op 2010-06-21 15:38, Mattias Gaertner het geskryf: > Unless you use the same paths, no value is lost. Sorry Mattias, but you are wrong. TXMLConfig shows the exact same issue as TJSONConfig. Here is the output after the test run. I attached the xmlconfig test suite. Test is simple: - load form 1 - load form 2 - close form 1 > which saves settings - close form 2 > which saves settings and overwrites everything. --- $ ./testxmlconf --format=plain -a Time:00.001 N:1 E:0 F:1 I:0 TTestXMLConfig Time:00.001 N:1 E:0 F:1 I:0 00.000 TestConcurrency Failed: Failed on 1 expected: <400> but was: <100> Number of run tests: 1 Number of errors:0 Number of failures: 1 List of failures: Failure: Message: TTestXMLConfig.TestConcurrency: Failed on 1 expected: <400> but was: <100> Exception class: EAssertionFailedError Exception message: Failed on 1 expected: <400> but was: <100> $ cat concurrency.xml --- -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ testsuite_xmlconf.tar.gz Description: GNU Zip compressed data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OpenSSL bindings improvement
Hello, I just commited my changes, because otherwise our work would conflict. Please work on top of this new version. I checked a lot of functions against OpenSSL 1.0.0 and it attested that they work fine. I added many structures and in added a mechanism to display which routines couldn't be found in the library. This can be useful because of the plethora of OpenSSL versions available which may not have all functions. In terms of functions I removed some functions which don't exist in v1.0.0 and added the following: + // RAND functions + TRAND_set_rand_method = function(const meth: PRAND_METHOD): cint; cdecl; + TRAND_get_rand_method = function(): PRAND_METHOD; cdecl; + TRAND_SSLeay = function(): PRAND_METHOD; cdecl; + TRAND_cleanup = procedure(); cdecl; + TRAND_bytes = function(buf: PByte; num: cint): cint; cdecl; + TRAND_pseudo_bytes = function(buf: PByte; num: cint): cint; cdecl; + TRAND_seed = procedure(const buf: Pointer; num: cint); cdecl; + TRAND_add = procedure(const buf: Pointer; num: cint; entropy: cdouble); cdecl; + TRAND_load_file = function(const file_name: PChar; max_bytes: clong): cint; cdecl; + TRAND_write_file = function(const file_name: PChar): cint; cdecl; + TRAND_file_name = function(file_name: PChar; num: csize_t): PChar; cdecl; + TRAND_status = function(): cint; cdecl; + TRAND_query_egd_bytes = function(const path: PChar; buf: PByte; bytes: cint): cint; cdecl; + TRAND_egd = function(const path: PChar): cint; cdecl; + TRAND_egd_bytes = function(const path: PChar; bytes: cint): cint; cdecl; + TERR_load_RAND_strings = procedure(); cdecl; + TRAND_poll = function(): cint; cdecl; + + // RSA Functions + TRSA_new = function (): PRSA; cdecl; + TRSA_new_method = function (method: PENGINE): PRSA; cdecl; + TRSA_size = function (arsa: PRSA): cint; cdecl; + TRsaGenerateKey = function(bits, e: cInt; callback: PFunction; cb_arg: SslPtr): PRSA; cdecl; + TRSA_generate_key_ex = function (arsa: PRSA; bits: cInt; e: PBIGNUM; cb: PBN_GENCB): PRSA; cdecl; + TRSA_check_key = function (arsa: PRSA): cint; cdecl; + TRSA_public_encrypt = function (flen: cint; from_buf, to_buf: PByte; arsa: PRSA; padding: cint): cint; cdecl; + TRSA_private_encrypt = function (flen: cint; from_buf, to_buf: PByte; arsa: PRSA; padding: cint): cint; cdecl; + TRSA_public_decrypt = function (flen: cint; from_buf, to_buf: PByte; arsa: PRSA; padding: cint): cint; cdecl; + TRSA_private_decrypt = function (flen: cint; from_buf, to_buf: PByte; arsa: PRSA; padding: cint): cint; cdecl; + TRSA_free = procedure (arsa: PRSA); cdecl; + TRSA_flags = function (arsa: PRSA): Integer; cdecl; + TRSA_set_default_method = procedure (method: PRSA_METHOD); cdecl; + TRSA_get_default_method = function : PRSA_METHOD; cdecl; + TRSA_get_method = function (prsa: PRSA): PRSA_METHOD; cdecl; + TRSA_set_method = function (arsa: PRSA; method: PRSA_METHOD): PRSA_METHOD; cdecl; + + // X509 Functions + + Td2i_RSAPublicKey = function (arsa: PPRSA; pp: PPByte; len: cint): PRSA; cdecl; + Ti2d_RSAPublicKey = function (arsa: PRSA; pp: PPByte): cint; cdecl; + Td2i_RSAPrivateKey = function (arsa: PPRSA; pp: PPByte; len: cint): PRSA; cdecl; + Ti2d_RSAPrivateKey = function (arsa: PRSA; pp: PPByte): cint; cdecl; + + // ERR Functions + + TErr_Error_String = function (e: cInt; buf: PChar): PChar; cdecl; + + // Crypto Functions + + TSSLeay_version = function(t: cint): PChar; cdecl; + + // EVP Functions + + TOpenSSL_add_all_algorithms = procedure(); cdecl; + TOpenSSL_add_all_ciphers = procedure(); cdecl; + TOpenSSL_add_all_digests = procedure(); cdecl; + // + TEVP_DigestInit = function(ctx: PEVP_MD_CTX; type_: PEVP_MD): cint; cdecl; + TEVP_DigestUpdate = function(ctx: PEVP_MD_CTX; const data: Pointer; cnt: csize_t): cint; cdecl; + TEVP_DigestFinal = function(ctx: PEVP_MD_CTX; md: PByte; s: pcuint): cint; cdecl; + // + TEVP_get_cipherbyname = function(const name: PChar): PEVP_CIPHER; cdecl; + TEVP_get_digestbyname = function(const name: PChar): PEVP_MD; cdecl; + // + TEVP_CIPHER_CTX_init = procedure(a: PEVP_CIPHER_CTX); cdecl; + TEVP_CIPHER_CTX_cleanup = function(a: PEVP_CIPHER_CTX): cint; cdecl; + TEVP_CIPHER_CTX_set_key_length = function(x: PEVP_CIPHER_CTX; keylen: cint): cint; cdecl; + TEVP_CIPHER_CTX_ctrl = function(ctx: PEVP_CIPHER_CTX; type_, arg: cint; ptr: Pointer): cint; cdecl; + // + TEVP_EncryptInit = function(ctx: PEVP_CIPHER_CTX; const chipher_: PEVP_CIPHER; + const key, iv: PByte): cint; cdecl; + TEVP_EncryptUpdate = function(ctx: PEVP_CIPHER_CTX; out_: pcuchar; + outlen: pcint; const in_: pcuchar; inlen: cint): cint; cdecl; + TEVP_EncryptFinal = function(ctx: PEVP_CIPHER_CTX; out_data: PByte; outlen: pcint): cint; cdecl; + // + TEVP_DecryptInit = function(ctx: PEVP_CIPHER_CTX; chiphir_type: PEVP_CIPHER; + const key, iv: PByte): cint; cdecl; + TEVP_DecryptUpdate = function(ctx: PEVP_CIPHER_CTX; out_data: PByte; + outl: pcint; const in_: PByte; inl: cint): cint; c
Re: [fpc-devel] Rather large flaw in TJSONConfig component
On 21 June 2010 15:10, Graeme Geldenhuys wrote: > Op 2010-06-21 15:34, Henry Vermaak het geskryf: >> >> Seriously, would you try the same thing with a file? > > Seriously, you would want to tell developers in todays times that they > can't concurrently access a file? No, that's not what I'm saying. You need to make it work. Your complaint is like saying the write syscall doesn't do the right thing when I use it on the same file from two different places. It _can_ work, but it's your job to do it correctly. >> Programs that want to write to the same json file from >> different classes need to handle this properly, just like they would >> have to when using files. > > Unfortunately TJSONConfig and TXMLConfig encapsulates the file handling - > it's not available to the developer to change. So the file handling fix > needs to occur in these components themselves. You can create a class that wraps all the json operations, and therefore handle concurrency in one place. You're only using one json file after all. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
On Mon, 21 Jun 2010 16:17:32 +0200 Graeme Geldenhuys wrote: > [...Sorry, I think my first message's attachment was too big. This one > is smaller...] > > On 21/06/2010, Mattias Gaertner wrote: > > > > TXMLConfig reads by default the old config. > > Unless you use the same paths, no value is lost. > > > Op 2010-06-21 15:38, Mattias Gaertner het geskryf: > > Unless you use the same paths, no value is lost. > > Sorry Mattias, but you are wrong. TXMLConfig shows the exact same issue as > TJSONConfig. Here is the output after the test run. I attached the > xmlconfig test suite. > > Test is simple: > - load form 1 > - load form 2 > - close form 1 > which saves settings > - close form 2 > which saves settings and overwrites everything. Now I understand. Yes, TXMLConfig has the same "design flaw" as TStringList.LoadFromFile/SaveToFile. It is strange how you get used to such flaws and think it is normal. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
On Mon, 21 Jun 2010, Graeme Geldenhuys wrote: Hi, Attached is a patch which extents the jsonconf test suite. The new test highlights a rather big flaw in the workings of the TJSONConfig component. This issue might even apply to TXMLConfig component too - I haven't looked yet. This came about in the discussion in the Lazarus mailing list about Lazarus IDE storing application settings in XML files. I investigated the idea of replacing my usage of INI files for storing application settings with JSON files (TJSONConfig) instead. In each of my applications, I store all GUI Form state (position, size, etc) all in one "application settings" file - each form has it's own XXXFormState section. The same happens if you use .INI files. I don't see this as a problem. The best way to avoid it is to create/destroy the config object after use. When the form is opened, you create an ini/json/whatever file object and read the data. Then destroy. When The form is closed, again create the file object (it should read the latest version of the file then) and then save changed values and destroy. Likewise for a database application. Unless you take care of transaction support, 2 users editing a record will overwrite each other's changes, unless the programmer explicitly takes care of this. In 12 years that our apps run, we used the system 'last writer wins' and no single user has complained yet about this. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
Op 2010-06-21 16:29, Henry Vermaak het geskryf: > > You can create a class that wraps all the json operations, and > therefore handle concurrency in one place. Correct, that's one possible solution like I mentioned with the Singleton design pattern. But this still leaves the door wide open for others to have this problem because the actual TXXXConfig component doesn't do the "singleton/concurrency" by itself - and not many developers seem to know about this issue or know about the Singleton design pattern. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
On 21 June 2010 15:35, Graeme Geldenhuys wrote: > Op 2010-06-21 16:29, Henry Vermaak het geskryf: >> >> You can create a class that wraps all the json operations, and >> therefore handle concurrency in one place. > > Correct, that's one possible solution like I mentioned with the Singleton > design pattern. But this still leaves the door wide open for others to have > this problem because the actual TXXXConfig component doesn't do the > "singleton/concurrency" by itself - and not many developers seem to know > about this issue or know about the Singleton design pattern. My point is that this is the wrong place to build such functionality in. How do you propose this should work from different files or processes? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
Op 2010-06-21 16:31, Mattias Gaertner het geskryf: > > Now I understand. > Yes, TXMLConfig has the same "design flaw" as > TStringList.LoadFromFile/SaveToFile. > It is strange how you get used to such flaws and think it is normal. Like I said, if nothing gets changed in the TXXXConfig components, then Lazarus IDE leaves the door wide open for developers to make this mistake. Why, because Lazarus IDE has a TXMLConfig component on the component palette. Developers wouldn't think twice that they are not allow to drop one component on each form and have a data loss issue. Possible solutions: * Fix TXXXConfig components to handle concurrency (multiple instances). More intelligent file handling. * Implement a Singleton for each TXXXConfig component which is ready to use for by the developer. Just like Application and Screen are single instances in a application without the developer needing to do anything. * Lazarus could maybe warn the developer (with a popup message) if they drop more than one TXXXConfig component in a project with same Filename value. * Or TXMLConfig must be removed from Lazarus component palette as it's not like all other components that can handle multiple instances without problems. * Or remember to add clear documentation (when it is written) about this pitfall with TXXXConfig components. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
Op 2010-06-21 16:33, Michael Van Canneyt het geskryf: > > The best way to avoid it is to create/destroy the config object after use. > When the form is opened, you create an ini/json/whatever file object and So then it's not wise to have TXMLConfig in the Lazarus component palette. Because dropping a component on a form doesn't give the behaviour you described. > Likewise for a database application. Unless you take care of transaction > support, 2 users editing a record will overwrite each other's changes, > unless the programmer explicitly takes care of this. Doesn't Delphi's TClientDataset popup a 'conflict resolution dialog' in such a cases. I remember seeing such dialogs years ago (when I still used Delphi). > In 12 years that our apps run, we used the system 'last writer wins' and > no single user has complained yet about this. Because they don't get notified about their data (last saved) being lost. :-) Michael, how does documentation work in FCL? Can we start documentation on these units and include these usage warnings - then not let them appear in official documentation until the FCL-json or FCL-xml packages are 100% documented? I know FPC has the policy that it doesn't allow "partial" documentation. I just fear that not documenting it now (somewhere) - this information will be forgotten when the docs are eventually written. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Rather large flaw in TJSONConfig component
On Mon, 21 Jun 2010, Graeme Geldenhuys wrote: Op 2010-06-21 16:33, Michael Van Canneyt het geskryf: The best way to avoid it is to create/destroy the config object after use. When the form is opened, you create an ini/json/whatever file object and So then it's not wise to have TXMLConfig in the Lazarus component palette. Because dropping a component on a form doesn't give the behaviour you described. It does if you set 'active' or 'enabled' to false, no ? Likewise for a database application. Unless you take care of transaction support, 2 users editing a record will overwrite each other's changes, unless the programmer explicitly takes care of this. Doesn't Delphi's TClientDataset popup a 'conflict resolution dialog' in such a cases. I remember seeing such dialogs years ago (when I still used Delphi). Only if you program it so. I program with UpdateMode=upWhereKeyOnly, and then all updates go through, unless the record was deleted. In 12 years that our apps run, we used the system 'last writer wins' and no single user has complained yet about this. Because they don't get notified about their data (last saved) being lost. :-) Well, I prefer that over bugging our users with dialogs that they don't understand anyway. Additionally, it drastically degrades performance. Michael, how does documentation work in FCL? Can we start documentation on these units and include these usage warnings - then not let them appear in official documentation until the FCL-json or FCL-xml packages are 100% documented? I know FPC has the policy that it doesn't allow "partial" documentation. I just fear that not documenting it now (somewhere) - this information will be forgotten when the docs are eventually written. You can start documenting them if you wish. But they won't be included in the official docs till fully finished. (Actually, I started on fcl-json to get it included on www.json.org. Documentation is a prerequisite) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OpenSSL bindings improvement
2010/6/21 Felipe Monteiro de Carvalho : > Hello, > > I just commited my changes, because otherwise our work would conflict. > Please work on top of this new version. Your changes include mostly mine. I will check the Delphi compatibility ( ctypes.pp has to be modified ). Thanks. -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Two fpimage questions
Hello Can I resample / resize an TFpMemoryImage without losing the alpha channel? If I use StretchDraw, the resulting image is no longer alpha-transparent. Am I missing sth.? Ist it possible to unregister / replace an fpimagereader? I saw they are registered in the initialization section using ImageHandlers.RegisterImageReader (.. Thank you Best regards Theo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OpenSSL bindings improvement
thanks, applied in rev15469 -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Two fpimage questions
On Mon, 21 Jun 2010, theo wrote: Hello Can I resample / resize an TFpMemoryImage without losing the alpha channel? If I use StretchDraw, the resulting image is no longer alpha-transparent. Am I missing sth.? It probably depends on the default stretching algorithm ? Ist it possible to unregister / replace an fpimagereader? I saw they are registered in the initialization section using ImageHandlers.RegisterImageReader (.. You cannot. A workaround is maybe to keep references to all registered handlers, free the manager, recreate it and re-register all handlers except the one you want removed. Please file a bugreport (feature request) so a handler can be un-registered. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Two fpimage questions
>You cannot. A workaround is maybe to keep references to all registered handlers, free the manager, recreate it and re-register all handlers except the one you want removed. Please file a bugreport (feature request) so a handler can be un-registered. Thanks. I've tried that, and it works. But I saw that Lazarus is not using these registered handlers, so it doesn't really help me. For the record: Om:=ImageHandlers; ImageHandlers:=TImageHandlersManager.Create; for i:=0 to Om.Count-1 do begin tn:=Om.TypeNames[i]; ext:=Om.Extentions[tn]; ir:=Om.ImageReader[tn]; iw:=Om.ImageWriter[tn]; if tn<>'JPEG Graphics'then if ir<>nil then ImageHandlers.RegisterImageReader(tn,ext,ir); if iw<>nil then ImageHandlers.RegisterImageWriter(tn,ext,iw); end; Om.Free; Thank you Michael! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Two fpimage questions
>You cannot. A workaround is maybe to keep references to all registered handlers, free the manager, recreate it and re-register all handlers except the one you want removed. Please file a bugreport (feature request) so a handler can be un-registered. Thanks. I've tried that, and it works. But I saw that Lazarus is not using these registered handlers, so it doesn't really help me. For the record: Om:=ImageHandlers; ImageHandlers:=TImageHandlersManager.Create; for i:=0 to Om.Count-1 do begin tn:=Om.TypeNames[i]; ext:=Om.Extentions[tn]; ir:=Om.ImageReader[tn]; iw:=Om.ImageWriter[tn]; if tn<>'JPEG Graphics'then if ir<>nil then ImageHandlers.RegisterImageReader(tn,ext,ir); if iw<>nil then ImageHandlers.RegisterImageWriter(tn,ext,iw); end; Om.Free; Thank you Michael! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel