Anders Melander

PDF? Not really the same as "pdb" 🙂 Anyway there are plenty of other Hex editors but I think it's bad form to hijack this announcement thread to discuss that.

I just tried NativeJpg32, and while it has quite a few more dependencies (on the other SimDesign units) than what I would have liked, it worked well on everything I threw at it. With regard to memory usage I tried loading a 16.4 Gb jpeg file (7900x5430 pixels) into a TBitmap32. The TBitmap32 as expected consumed 163 Mb. The peak overhead during load and conversion was 600 Mb. Loading the same image as a BMP into TBitmap32 and then converting it to JPEG caused a peak overhead during conversion of 675 Mb and resulted in a jpg filesize of 11.1 Mb. Of course the two file were no longer identical due to the lossy jpeg encoding. I did not experience any leaks.

Nope. Have you read the section "How to handle source code changes"? O.M.<expletive>G.

This one seems to do just that: https://github.com/taazz/simdesign/blob/87fdcc43f3a71016280cdbfc11de6cf4dd836254/simlib/nativejpg/NativeJpg32.pas Haven't tried it though.

Excellent. Can't wait to give it a spin.

That's what she said Sorry

There are undoubtedly different opinions about this but I would say that you should completely separate design- and compile-time stuff. Build and install your design-time package and never mind where the dcu files for that are located. Just don't have them output to the same folder as the source. I would probably place them (via the package project options) in a sub-folder of the package source but you could just as well delete them once the package is installed because they are only needed to build the package. Reference the source files directly, or via the search path, in your project and have the dcu's output to the project dcu folder. Do not include the dcu output folder in your project search path.

Impressive! I could have used this when I reverse engineered the pdb file format. I have one suggestion based on a quick look though the source: It seems data is read unbuffered and edits are done directly on the source (file/disk/memory). This is fine as it allows one to edit huge binary files without loading them into memory (which surprisingly is what many other hex editors does). One thing I could wish for would be a mode that cached edits in memory and then allowed those edits to be applied/committed to the source on demand. You could probably implement this with a block cache layer on top of your existing data source layer.

Sure, but that's hardly worth USD 600/year. Most of the stuff on that list is just repackaging of their existing features. Pfft!

Fork the repository. Create a branch on your fork. Apply the changes to your branch. Push the changes to your fork. Create a pull request to have your branch merged into the original repository.

Do you have AutoSize=True on the labels?

You can create a run-time package containing synedit (a run-time package is a DLL) and link against that but one way or the other you are going to create a dependency on synedit and compiling it directly into your project is the the option that will give you the least problems.

Not very shocking if you understood what was going on. When you install a component your code will be run as a part of the IDE process. If your component code goes into an endless loop then you will have hung the IDE. Nothing surprising there. So is Delphi. I'm assuming you're a hobbyist because otherwise VS isn't free AFAIK.

No you don't. I understand why you used it but there are always better ways to solve a problem than using [weak]. Contrary to what the documentation states [weak] isn't named named after the type of reference. It's named after the design skills of people who choose to use it to manage references. 🙂

P.S. Tabs are Evil!

Why? What problem are you trying to solve? While I'm definitely a proponent of interfaces at a higher level, at low level they often just obfuscate the code. Apart from that I think your solution has a number of "smells": Why is the TDrawingObject.ObjectType writable? Does the ObjectType really need to change after construction? Why is TDrawingObject.DrawingObjectsList writable? Who owns the list? (might have been covered before. TL;DR) Instead of exposing the whole TObjectList<> class, expose only the relevant parts (Add, Remove, Enumerator). See: Why is TDrawingObjectsList.OwnsObjects part of the API? Isn't the ownership an implementation detail?

So evidently there's another problem with your code. You can start by showing us the call stack (click the Details button).

Don't insert tabs in your source. Don't use [weak] Use the notification mechanism built into TComponent: type TComponentA = class(TComponent, IComponentAl) private FComponentB: TComponentB; private procedure SetComponentB(const Value: TComponentB); protected procedure Notification(AComponent: TComponent; Operation: TOperation); override; published property ComponentB: TComponentB read FComponentB write SetComponentB; end; procedure TComponentA.SetComponentB(const Value: TComponentB); begin if (FComponentB <> nil) then FComponentB.RemoveFreeNotification(Self); FComponentB := Value; if (FComponentB <> nil) then FComponentB.AddFreeNotification(Self); end; procedure TComponentA.Notification(AComponent: TComponent; Operation: TOperation); begin inherited; if (AComponent = FComponentB) and (Operation = opRemove) then FComponentB := nil; end;

https://torry.net/pages.php?id=112#939914 It probably doesn't work with the current version of Graphics32, because the GR32 polygon classes has been redesigned since it was written, but it will probably work with the version of Graphics32 available on the same page at torry.net That's correct. It's abandonware but that's not been a problem for me in the one project were it's used since it's a fairly small library and the functionality is limited. AFAIR it took me about an hours to integrate it into the application where it's used but of course I already knew Graphics32 so that helped a lot. Let me know if you want to see the source of the unit using it. To each their own - but I think I could have typed 200 lines of code in the time it has taken me to locate the library and write this message 🙂

Unless you're working on a 1970s vector monitor all vectors eventually ends up as raster graphics... Graphics32 has a pretty extensive (and fast) vector layer. Image32 is the same in that regard; A vector layer on top of a raster layer. I would have thought that GR32_Objects would fit the bill but it seems like the couple of hundred lines of code required to implement a complete object based vector drawing application is too large an effort.

I found a copy in one of my old projects. Attached. But... Instead of using 25 year old, undocumented, and probably superseded APIs it might be a better idea to use something like WMI. There are lots of libraries that makes use of WMI easy from Delphi. This one for example: https://bitbucket.org/anders_melander/windows-management-wrappers/src/master/Source/amWindowsManagementInstrumentation.pas NTUnits100.zip NTLowLevel100.zip

Law of Triviality. Every body's got an opinion about the bike shed but do we really need a video and an endless thread about it?

On a positive note: 11,156 dreaded Python while only 797 dreaded Delphi... From that we can conclude that Python is almost 14 times more unpopular than Delphi! Woohoo!

...and PowerShell pays 15% better than C, C++ and C#... Yeah, right - but then again, you'd have to throw really big bucks at me to get me to touch that crap.