Anders Melander

Just now, 357mag said:

That won't work either.

Yes it does. Try again and this time do it exactly like Uwe showed you.

Stack tracing is very expensive and not all exceptions are errors.

12 minutes ago, 357mag said:

Just wondering what would be some good naming abbreviations

Don't.

You aren't improving anything by abbreviating control names.

5 hours ago, Berocoder said:

the huge amount of data we have.

It sounds to me like you have a quality problem if you have that many exceptions.

In the applications that I work on (users in the hundreds), every single exception that are caught by the outer exception handler (madExcept in our case) is treated as a must-fix bug. On the average I would say we get one or two a month if we've been sloppy with the QA.

The madExcept bug reports are usually either mailed to us by the madExcept UI, or retrieved from the customer's system by our supporters, and attached to a JIRA issue. It is extremely rare that we need to compare call stacks to detect a duplicate. AFAIK madExcept can do so automatically via a hash or something but we've never used that feature.

So the only advice I can offer is: fix your bugs before release 😉 

18 minutes ago, Die Holländer said:

Maybe one of these LLM answers can give you some clue..

Useless.

6 minutes ago, Rollo62 said:

Sorry, what are you looking for?

// A single item
var state : TShiftStateItem =   ssShift;
// or
// A set with a single item only
var state : TShiftState     = [ ssShift ];

 

That's assignments. OP is asking for a type declaration.

2 hours ago, weirdo12 said:

there is no need to store TBitmapLayer* at all (except for convenience as a temporary so that it can be initialized as required). The best practice is to always access a layer through ImageBackground->Layers->Items.

Yes, that's correct; There no need. But I don't see a problem with saving a direct reference somewhere else, for convenience, performance, or readability.

In Delphi, I would do something like this:

// Create layer
var Layer := Image.Layers.Add<TBitmapLayer>;

// Set initial layerproperties
Layer.Scaled := True;
Layer.Bitmap.LoadFromFile('foo.png');
...

or

interface

type
  TMyForm = class(TForm)
  private
    FBitmapLayer: TBitmapLayer;
    ...
  public
    constructor Create(AOwner: TComponent); override;
  end;

implementation

constructor TMyForm.Create(AOwner: TComponent);
begin
  inherited;
  FBitmapLayer := Image.Layers.Add<TBitmapLayer>;
  FBitmapLayer.Scaled := True;
end;

procedure TMyForm.SomeMethod;
begin
  FBitmapLayer.Bitmap.LoadFromFile('foo.png');
  ...
end;

12 hours ago, weirdo12 said:

Another approach is to use std::vector<std::unique_ptr<TBitmapLayer>>  created by std::make_unique instead of using an array of raw TBitmapLayer pointers which can lead to memory unsafe code. When the std::vector is destroyed (goes out of scope) everything gets cleaned up.

Having two list think they "own" the same object would be a very bad idea; The layers are already owned and managed by a layer collection.

3 hours ago, David Schwartz said:

Is it useful without a run-time license for DevEx?

My debugger requires DevExpress but DWScript itself has no external dependencies.

I chose to use DevExpress mainly because I wanted a docked layout and from prior experience I know that the VCL's docking suuuucks. It should be possible to replace it with something else, if one wanted to.

I also have a DWScript RTL that uses DevExpress controls for the GUI stuff but you don't need to use my RTL; DWScript comes with its own non-UI RTL that covers the basic stuff.

Actually, AFAIK, I'm the only one doing UI with DWScript. At least I haven't seen anyone else do it.

3 hours ago, David Schwartz said:

if you use generic Delphi code that can be tested in Delphi then loaded somewhere to run under DWScript, can you get by without DevEx?

Yes.

I have used DWScript as a scripting system in several products. Used either to provide business rules (no UI, just logic) or as a app/plugin (with UI).

The OP language support and performance is excellent. The learning curve is extremely high (no documentation, few examples).

Here's an IDE/debugger I wrote for it: DWScriptStudio

FWIW, https://www.beginend.net is powered by DWScript.

2 hours ago, Berocoder said:

When I transfer a form, pas-file and dfm-file from 12.2 to 11.3 I got this error in 11.3

1. It's been like that since Delphi 2.
2. Why do you need to open a form in Delphi 11 that has been saved with Delphi 12?
3. Regardless of this problem, you should always "be careful what you commit"; Review your changes and cherry pick the ones that are relevant so the important changes aren't drowned out by the noise.

Order incoming...

Now we just need to get the EV-vetting process completed.

It also tells which layer produced the error. For example, was it the DB server, the DB client library, or FireDAC itself.

It's technical info that provides important context to the developer/supporter. It's not meant to be presented to the user.

Just now, Rollo62 said:

pre-chop the large BMP into smaller BMP tiles, and show, pan and zoom through these smaller chunks only

Sure, that'd work. Not a small task though.

1 hour ago, Rollo62 said:

Ok, if all this is nonsense

It is.

There is zero benefit in memory mapping a bitmap file. None. Zip.

36 minutes ago, Rollo62 said:

A Linear, decompressed Bitmap-File should be possible to handle, without loading it completely into memory first.

You haven't thought this through. Try it - at least on paper.

15 hours ago, NecoArc said:

var
bitmap:TBitmap
begin
    lbName.text:=product.name;

    bitmap := tbitmap.create;
    bitmap.setSize(TSize.create(200,200));
    bitmap. LoadFromFile(imagePath);
    Timage.bitmap.assign(bitmap);
    bitmap.free;

end

1. There's no point in sizing the bitmap just before you load something into it.
2. Instead of loading into a TBitmap and then copying that into TImage, load directly into the destination bitmap.

but this isn't the cause of you problems.

Your source images are compressed PNGs. Once they are loaded into a TBitmap they have been decompressed so they will use a lot more memory that what their size is on disk.

The images probably also have a resolution higher that what you can display. So instead of displaying the image in their original size/resolution, resize (resample is the correct term) them on load to fit the destination viewport. Keep the resized bitmap in memory and discard the original (from memory that is. You still have it wherever you loaded it from). So you are basically displaying thumbnails of the original images.

Just now, Rollo62 said:

Because, if you Zoom or only want to show parts of the file, you eventually don't need to load it all.

Unless you actually know how to do this I don't think you should offer it as a possible solution.

Assuming the image file is uncompressed, you would need to at least load the header. Then you would need to locate and load the partial image rows and then you would need to reassemble this into something that can be processed as a bitmap and then that would need to be scaled to fit the viewport. I doubt this would improve the performance.

If the image is compressed then it will have to be decompressed into memory before it can be displayed. The RAM has already been allocated; Game over.

6 minutes ago, Rollo62 said:

Why is Google Maps not showing always the whole earth, but only tiles of it?  🤔

Is that a serious question?

Google Maps, and other GIS systems, display tiles because that is how their data is organized. As far as I can tell we are not dealing with tiled image data in this case.

Anyway, back to memory mapping; If anything, using memory mapped files would increase the RAM usage, so I still fail to see how that would improve the situation.

38 minutes ago, Rollo62 said:

Perhaps its possible to read and show the images partly, as memory mapped files

Why would making an image file memory mapped reduce RAM usage?

Do you understand what mapping a file into memory does?

Just now, BKor said:

May I delete pLayer[j] (TImage32) in Form destructor anyway (although not necessary as you say)?

Sure, you can if you want to.

The layer will remove itself from the layer collection when it's destroyed so the layer will not be destroyed twice.

5 hours ago, Remy Lebeau said:

__fastcall TForm1::~TForm1()
{
	...
	for(int j = 0; j < c; ++j)
	{
		delete pLayer[j];
	}
	...
}



This isn't necessary in this particular case; The TImage32 owns the layers and will automatically destroy them.

11 hours ago, Anders Melander said:

and I can't make it match with what I see on your repos.

...and FWIW your old SuperLemmix repo on BitBucket appears to be gone. Now I only see the NeoLemmix repo.

I can't follow your description above and I can't make it match with what I see on your repos.

I suggest you:

1. Ditch BitBucket - it sucks.
   Use your repo on github instead.
2. Ditch SourceTree - see above.
   Install Fork.

If you tell me what the source and target branches are I can tell you how to do it.

Well, that would certainly explain the symptoms we're seeing.

10 minutes ago, BKor said:

When compiling it gives: 

Access violation at address 6CE9D636 in module 'rtl290.bpl' (offset 11D636). Read at address 006C005E.

Are you saying that you get an exception when compiling the code? I think you mean when running the code.

Going back and looking at your screenshots, I can see that the exception probably occurs in some paint code. That's why you get the cascading errors. A repaint causes an error which triggers a new repaint which causes an error, etc. etc.

2 minutes ago, BKor said:

I was wrong. Rewriting the code in RadStudio 12 did not work.

If you can reduce the project to the smallest possible case that reproduces the problem and post the code in a zip file, then maybe some of those here that actually use C++ (I don't) can have a go at it.

For example, if you remove all the 3rd party stuff (including Graphics32), can you still reproduce the problem?

4 minutes ago, BKor said:

I would like to delete some of my previous messages (ones with tons of images), is this possible?

No.