eivindbakkestuen

Probably the printer was offline or unreachable before; and then it was reachable. This happens every day here when trying to print from many, even well known applications; they take forever to time out if the default printer wasn't turned on. You could try using a worker thread for printing, then your application doesn't freeze and you have some control over what happens

It is a documentation omission, the help on the link states "You can only rely on the final value of a for loop control variable if the loop is left with a goto or exit statement. " In https://docwiki.embarcadero.com/RADStudio/Athens/en/Declarations_and_Statements_(Delphi)#For_Statements it says "After the for statement terminates (provided this was not forced by a Break or an Exit procedure), the value of counter is undefined. " The value should be defined, as the loop here exits with a Break,

Use a separate "master" thread to call WaitForAll. Are you already using TThread.Synchronize for the memo updates?

If your application has bugs, sure...

What problem are you trying to solve?

Using the WrapDelphi and associated classes, I have probably missed it, but I couldn't see an equivalent to the CreateComponent() method to create non-TComponent descendant classes, eg TStringList etc which I needed for things in the .PY script below. Is there an existing way of creating such classes on the fly in the .PY script? ... db = CreateComponent("TnxDatabase", None) sl = TStringList (?) db.GetTableList(sl) print(*sl) ... I added the following method and registered it, and now I can do sl = CreateClass("TStringList", None) and it works. If there's no such built in method, feel free to assimilate this method into the WrapDelphi unit. 🙂 function TPyDelphiWrapper.CreateClass(pself, args: PPyObject): PPyObject; // Exposed function at the Module level // CreateClass(ClassName, Owner) var KlassName : PAnsiChar; _obj : PPyObject; Klass : TClass; _comp : TObject; TheClass : TObject; Ownership : TObjectOwnership; begin Result := nil; CheckEngine; with Engine do begin if PyArg_ParseTuple( args, 'sO:CreateDelphiClass', @KlassName, @_obj ) <> 0 then begin try Klass := GetClass(string(KlassName)); except Klass := nil; end; if (Klass = nil) or not Klass.InheritsFrom(TObject) then begin PyErr_SetString(PyExc_TypeError^, PAnsiChar(EncodeString( Format(rs_ErrInvalidArgs, ['CreateClass', rs_InvalidClass])))); Exit; end; TheClass := TClass(Klass).Create; Ownership := soOwned; Result := Self.Wrap(TheClass, Ownership); end else PyErr_SetString(PyExc_TypeError^, PAnsiChar(EncodeString( Format(rs_ErrInvalidArgs, ['CreateClass', ''])))); end; end;

Thanks a million! With the latest version, I no longer see the memory leak.

I'm using the WrapDelphi unit in a project, so that the TPyDelphiWrapper.CreateComponent function can be available from a Python script. Now, a clever user has come up with a "smart" way of finding available classes; namely, iterate over every possible string of characters and feed the strings into CreateComponent() in the Python script, and catch exceptions raised when the classname doesn't exist. Yes, due to the exponential nature of the search as the strings get longer, its not really a good way of finding long classnames. However, the problem I'm being presented with is that memory runs out long before time does. I have narrowed the problem down to the following (commented out by me for test) PyErr_SetObject call in TPyDelphiWrapper.CreateComponent(). if (Klass = nil) or not Klass.InheritsFrom(TComponent) then begin // PyErr_SetObject(PyExc_TypeError^, PyUnicodeFromString( // Format(rs_ErrInvalidArgs, // ['CreateComponent', rs_InvalidClass]))); Exit; end; The inner function in the Python script is the following. My question is, is there something different that needs to be called from the Python script, in order to release memory used by the exception? def typename(k, prefix="T", ab=alphabet): try: w = prefix + int2word(k, ab=ab) t = CreateComponent(w, None) out = ["T" + type(t).__name__] t.Free() del t except: out = [] return out

Having just installed Delphi 12.2, I'm seeing something I've not seen before. I have the grep results panel docked on the right with the project manager etc; somehow it is now displaying content matching the form designer, or the source editor, switching with each F12 press. Anyone else seen anything like this? I'm not sure exactly what I did to trigger it, and it didn't happen again after restarting the IDE.

Notice the "Post" part? I'm guessing the error doesn't occur in .Post, but in .Edit.

Ok, thanks!

I'm playing around with Demo31, its very neat that we can do things like this in the .py script: mytestform = CreateComponent("TForm", None) mytestform.Caption = 'Hello Delphi-PRAXIS' mytestform.Height = 1000 mytestform.ShowModal() However, it would be even cooler if it was possible to use the Pascal style of creation: mytestform = TForm.Create() Unfortunately, playing around with the DelphilWrapper classes hasn't lead to anything working; I've tried things like these PyDelphiWrapper.RegisterDelphiWrapper(TPyClassWrapper<TForm>).Initialize; ...or... PyDelphiWrapper.WrapClass(TForm); Is there any way of registering Delphi classes, such that the someclass.Create() syntax would work in a .py script?

There is no such version...

This is actually wrong or at least misleading; you should *not* uninstall manually before installing an update to a major version! Instead, you should let the new installer do the uninstall of the old version (it does this as part of the install), and don't change the default "not" setting in the dialog that asks you if you wish to remove registry settings.

Looks VCL themes related. What Delphi version? Reproducible in a simple test app?