Anders Melander

FWIW, I agree with @Khorkhe; The documentation for the Equal operator appears to be wrong.

Yes, you are going to use IOTA but you really need to read up on this topic until you understand it. The basic steps you must take is something like this (pseudo code; don't try to compile it): // Open the file in the IDE (BorlandIDEServices as IOTAActionServices).OpenFile('my_unit.pas'); // Get the file "module" var Module: IOTAModule := (BorlandIDEServices as IOTAModuleServices).FindModule('my_unit.pas'); // Iterate the module files for var i := 0 to Module.GetModuleFileCount-1 do begin // Get a module file editor var Editor: IOTASourceEditor; if not Supports(Module.GetModuleFileEditor(i), IOTASourceEditor, Editor) then continue; // Make the editor visible Editor.Show // Get an editor view if (Editor.GetEditViewCount = 0) then continue; var EditView: IOTAEditView := Editor.GetEditView(0); // Set the caret position var Position: TOTAEditPos; Position.Col := 1; Position.Line := ... EditView.SetCursorPos(Position); // Scroll to make caret visible and 15 lines down from the top Position.Line := Max(1, Position.Line-15); SetView.SetTopPos(Position); end;

There's one in DWScript: https://github.com/EricGrange/DWScript/blob/c3a26f0e68a5010767681ea1f0cd49726cd4af5d/Source/dwsUtils.pas#L3169 I haven't used it though but knowing Eric, it's probably both fast and well tested. Pity about the 3-space indents though; Very French 🙂 Other than that: https://github.com/search?q=lang%3Apascal+iso8601&type=code

Please google color quantization and dithering. Because that's exactly what you are doing.

You probably don't have the privileges to query all processes. Try running the application as administrator or elevate privileges from within your application. https://stackoverflow.com/questions/1435911/c-process-checking https://stackoverflow.com/questions/34511670/sedebugprivilege-and-openprocess-on-another-account

Sure, I could have sugar coated it better. The point was really that when the expectations turns out not to match reality then one should question the expectations first.

- Once you think about it.

Yes, that's normal. Right click in the Events pane, select Properties and then unselect Process, Thread and Module messages. Unless you really need the information it's just noise.

I think the MS documentation, while a bit terse, is clear enough; It specifies how the different properties and their limits relate to each other. The Delphi documentation though is severely lacking. If they had tried to document it properly they would probably have discovered that they got it wrong.

Is it a known problem that the VCL misinterprets the valid range of TScrollBar's PageSize and Max properties? TScrollBar enforces the rule that PageSize must be <= Max but Windows requires that PageSize be <= Max-Min+1... This means that if one sets PageSize=Max it is still possible to move the scrollbar +/-1 unit. One work around seems to be to set Min to 1 - because TScrollBar forgets to take Min into account when validating PageSize 🤦‍♂️ https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo

Maybe you should think a bit more about that. Ideally until it is no longer a mystery. What possible reason could there be for that limit? The 16x16 default is a big clue...

BL.Location := FloatRect(x1, y1, x2, y2);

It doesn't; It uses the map file.

Okay. It would be so much easier if you actually read and answered the questions I have asked you. The position and size of the layer determines where the bitmap is drawn. Isn't that what you are seeing?

I have no idea what you mean

And what is the actual result?

Show us what you mean; We still can't read your mind. What does it look like? What do you want it to look like?

My bad. That should have been: BL.Location := FloatRect(ImgView.Bitmap.Width/4, ImgView.Bitmap.Height/4, ImgView.Bitmap.Width/4*3, ImgView.Bitmap.Height/4*3); as a rect is (x1,y1, x2,y2)

I think you forgot the price of a Windows license... I know it's possible to run Windows on a Raspberry Pi, I just don't think it makes sense from a business or performance POW.

If you mean the size of the layer, something like this: // Half size of background bitmap, centered BL.Location := FloatRect(ImgView.Bitmap.Width/4, ImgView.Bitmap.Height/4, ImgView.Bitmap.Width/2, ImgView.Bitmap.Height/2);

Okay, but: And don't include the exe or dcu files in your zip. Also, a description or a mockup of what you expected the result to be would also be needed; I can't read your mind. That said, You are not specifying the size/position of the bitmap layer. The size of the PNG (4774x4345) is much larger than the size of the background (1920x1247). That in itself is not a problem but the size does seem pretty excessive.

That sounds like a horrible idea. Why on earth would you run a desktop/server OS on an embedded device?

Without knowing the size of the base and layer bitmap I can't tell how their relative sizes should be. You have setup the layer scale to follow the base scale (Scaled=True), but have you specified the initial size of the layer? The ugly edges are most likely caused by having DrawMode=dmTransparent. You can experiment with layers and bitmaps using the Imgview_Layers example: If you continue having problems, please create an issue at the Graphics32 issue tracker: https://github.com/graphics32/graphics32/issues Include a minimal, reproducible example.

You don't need to use LoadBitmap32FromPNG; You can just use TBitmap32.LoadFromFile directly and let that figure the format out for you. BL.Bitmap.LoadFromFile('button.png'); Also, you should probably be using dmBlend DrawMode instead of dmTransparent: BL.Bitmap.DrawMode := dmBlend; dmTransparent is for color key transparency (like what TBitmap does). dmBlend is for alpha blending. What do you mean? What size is it? What size should it be?

Actually, that bitmap wasn't directed at your implementation in particular - because I haven't tried it; It's just a bitmap that Octree in general has problems with. But, I'll take it; You're welcome 🙂 The problem is that Octree doesn't reduce the root node (the MSB of the RGB, which represent 2^3=8 color cubes), or move colors between adjacent nodes. So lets say you are reducing an 1 billion pixel image with 1 million red/blue colors+1 green pixel. Octree will represent this as a MSB color cube that only contains a single color (green in this case) with a pixel count of 1 and a bunch of other cubes representing the other 1 million colors/1 billion pixels. If you now reduce this to 16 colors (or any other count for that matter) you will end up with green+15 red/blue colors. And that is just one of the problems with Octree. Of course you can tweak Octree to work around the various issues is has but I feel that that is just polishing a turd. That said, Octree is fast so one just have to be aware of the limitations and only use it when performance is more important than fidelity.