Jump to content

Zoë Peterson

Members
  • Content Count

    10
  • Joined

  • Last visited

  • Days Won

    2

Zoë Peterson last won the day on August 28

Zoë Peterson had the most liked content!

Community Reputation

10 Good

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Like Uwe said, I'm trying to serialize objects I don't control (stock VCL components), so I can't modify the original declarations. Part of is learning curve too. This started for personal use and I wasn't expecting to spend days researching JSON serializers. I started by just passing the base object into various framework's ObjectToJSON routines. Delphi's built-in ones fail with a marshalling error several layers deep, with no indication of what it was faulting on. Neon, I think, failed because it decided that the object should be stored as an array since it had a "Count" property, and there wasn't a way to force it to do otherwise. I looked at a few other frameworks too and don't remember exactly how they all came up short, but my starting point was "This is a TPersistent descendent that already has published properties; it should be easy to get at least a minimal export without doing anything fancy", and aside from mORMOT and TMS's FNC framework, that wasn't true. Other than that though, I largely agree with the arguments Dalija covered in her blog: Part 1, Part 2, Part 3, Part 4
  2. I did see that one in my search and should have looked at it more closely. Ultimately I avoided it because I was trying to stick to an open source library to make it easier to share the code, and then sort of forgot about it. 🙂 Nice! StyleObjects is definitely a better name for that part than "Objects" is. 🙂 The FNC version is missing a bunch of the data I had to manually construct in the mORMot version though: Colors, SysColors, and Fonts are public sub-objects of TSeStyleSource and none of them have properties that match the name/value pairs that they represent. That's what the "WriteColors", "WriteSysColors" and "WriteFonts" functions were doing, which were loosely based on the SaveToStream functions in the respective objects (TSeStyleColors, TSeStyleSysColors, TSeStyleFonts). The style objects also support nesting, and your version only includes the top-level of it.
  3. As Uwe said, that wouldn't have worked since the parent object was creating child objects of the appropriate type, and I don't have any control over that. For context, it was for a VCL style to JSON converter and I want to use the VCL's existing style loading code. Regardless, I still think it's weird that literally every JSON serialization library I could find relied on attributes and public/private fields. Delphi has had TPersistent and properties with 'stored' and 'default' and different names than the backing fields for its entire existence. They work well. It's great that the newer extended RTTI/attribute approach is available, but I absolutely do not understand why that's the only approach anyone's used.
  4. Understandable, and thank you for the initial posts. We have a settings framework internally that works that way and works great, but it uses XML and would have been hard to extract. By the time I'd gotten to your posts I'd already run through half a dozen different JSON serialization libraries that all used extended RTTI and attributes, and I was beginning to think I was crazy for expecting one to take advantage of Delphi's long established persistence support.
  5. I just released a converter to go from Delphi VCL/FireMonkey style files (.vsf) to a structured JSON dump. Embedded bitmaps are ignored, and it's one-way only, but it's handy for comparing changes. There's a Beyond Compare 4 file format available as well, though if you have questions/issues, post here or on the Github page rather than going through Scooter Software's official support. https://github.com/boramis/vsf2json
  6. Are there any object-to-JSON serialization libraries available that work with published properties (not public, not fields) and which allow customizing the serialization externally to the class? Dalija talked about this in her "When in Rome" series (https://dalijap.blogspot.com/2021/04/when-in-rome-do-as-romans-do-part-i.html) but didn't point to an alternative that worked that way. Any license is fine, though open source of some sort would be preferable. Specifically, I'm working with third party TComponent classes which already have most of their state exposed as published properties, and I can't add attributes to customize things. A couple of the components do use DefineProperties for some additional state when stored as DFMs, and I need to be able to register some sort of callback to serialize those. I was able to get close with mORMot's ObjectToJSON with RegisterCustomSerializer, but it doesn't support mixing published and custom properties in a single class. All of the other ones I've found do public/private fields, require attributes in the original classes, or fail in the marshalling step with unhelpful error messages. Edit: I figured a workaround using mORMot for my specific usage, so I don't need this anymore, though it is a bit hacky, so if there's a better approach, I certainly won't mind hearing it.
  7. Scooter Software has a full time Delphi developer position available, working on Beyond Compare, our file and folder comparison utility. Details available at https://www.scootersoftware.com/index.php?zz=job_opening
  8. Zoë Peterson

    TTitlebarpanel and VCL styles

    Is there a way to set the form's border color when using TTitleBarPanel if you're not using seBorder in the StyleElements? For our usage this would be workable short term, if I can tone down the bright white window frame
  9. Currently all of our forms are designed using Tahoma 8 at 96dpi and then scaled up at runtime based on the system font and DPI. That's been working great, but there's a snag with the newer DPI-based scaling in XE7+: since it doesn't scale based on the font anymore, loading on Vista/Win7/Win10 where they use Segoe UI 9 makes things too cramped/clipped. I could add a manual ChangeScale call at runtime to handle that, but since we're not targetting XP anymore, it would be nice to just scale all of our design-time forms once and move everything over to using Segoe UI all the time. Has anyone else run into this, and if so, any solutions besides hand adjusting hundreds of forms? A "Scale form by X%" IDE expert, for example?
×