Jump to content

pyscripter

Members
 View Profile  See their activity

  • Content Count

    779

  • Joined

  • Last visited

  • Days Won

    42

Posts posted by pyscripter

  3. Posted · Edited by pyscripter

    58 minutes ago, Gustav Schubert said:

    Detail noticed: Order is initially ok, IF the default style is not Windows (but for example Iceberg Classico) and only becomes problematic after switching to another VCL Style (other than Windows).
      

    
// order with default VCL style <> Windows, immediately after startup
TScrollingStyleHook.TScrollWindow
TScrollingStyleHook.TScrollWindow
TScrollingStyleHook.TScrollWindow
TScrollingStyleHook.TScrollWindow
TListView
TTreeView

// order after switching to VCL style <> Windows
TListView
TScrollingStyleHook.TScrollWindow
TScrollingStyleHook.TScrollWindow
TScrollingStyleHook.TScrollWindow
TScrollingStyleHook.TScrollWindow
TTreeView

    ( The order we always get with the workaround is the same as the initial order without workaround. )
     

    The question still remains why the change in the order results in the Treeview not receiving the WM_DESTROY message.  Why is the order important anyway in this issue?

  5. Posted

    @David MillingtonThe features of Parnassus Debugger are great, but I am getting assertion errors with the Parnassus Debugger and Delphi 10.4.2.  I am also getting Index out of bounds errors.  These occurred while debugging simple Vcl apps (nothing fancy) and they don't occur in the absence of the Parnassus Debugger.

     

    image.png.6b33e1fb3f33d2e0ce0fb2d67554368c.png

     

    Is https://quality.embarcadero.com/ the right place to report issues related to the Parnassus Debugger.

    • Like 2

  6. Posted · Edited by pyscripter

    The issue results from the TListView being recreated as a response to the CM_STYLECHANGED message (see CustomListView.WndProc).

     

    If you add the following at the top of UMainForm.pas

      

      TListView = class(Vcl.ComCtrls.TListView)
  protected
    procedure WndProc(var Message: TMessage); override;
  end;

    with the following implementation 

    procedure TListView.WndProc(var Message: TMessage);
begin
  if (Message.Msg = CM_STYLECHANGED)  then begin
    if ViewStyle = vsReport then
      UpdateColumns;
  end else
    inherited;
end;

    the error does not happen.   There does not appear to be much point in recreating the ListView, since its handle would have already been recreated, when the form it resides gets recreated.  Still it remains a mystery why the recreation of the ListView affects the TreeView!

     

    The memory leak is also prevented by calling RecreateWnd after changing the style.

     

    In the process of debugging, I discovered another Vcl bug: [RSP-33221] CM_STYLEDCHANGE is broadcast twice - Embarcadero Technologies

     

     

    • Like 2

  8. Posted

    On 2/24/2021 at 3:26 PM, balabuev said:

    What is interesting: removing the bottom list view will stop the bug from occurring.

    This is indeed weird.  In fact, just turning the Visible property of the ListView to False prevents the error.

     

    Some further observations:

    • I confirm that WMDestroy is not received by the treeview
    • The bug is definitely related to Vcl.Styles.  If you change the style to a Vcl.Style and then back to Windows, the error does not occur
    • You can prevent the error by calling Treeview.Items.Clear in the FormCloseQuery event handler.  Strangely calling RecreateWnd in the same handler also prevents the error.

  15. Posted · Edited by pyscripter

    18 hours ago, vmishka said:

    To make doubly sure that I don't mess anything up in the future: To arrange to develop 64-bit Windows applications using Python4Delphi, I can go back to the groupproj, change the target to Windows 64-bit for Python270.bpl, PythonVcl270.bpl, and PythonFmx270.bpl and then build each of those individually (no Build All). If I understand correctly, if that is successful, I am good to go (nothing else to install). Is that correct?

    No need for any of that, if you are not building applications with run-time packages and most likely you are not.  Just change the platform of your project to Win64 and build it.

  17. Posted

    3 hours ago, David Heffernan said:

    We use interfaces to wrap Python objects, and because they are also reference counter, that fits really nicely with the Python ref count.

    P4D does something similar with custom variants and the Varpyth unit.

  20. Posted · Edited by pyscripter

    4 hours ago, zMotoR said:

    All these decisions are on the Python side. 😞

    All of these suggestions can be implemented without modifying your python code.

     

    For example you can just add the suggested code to the PythonEngine.InitScript.

  22. Posted

    exit() raises the SystemExit exception, which unlike other exceptions, results in process termination before control gets back to Delphi.  To prevent process termination you can do one of the following:

     

    • wrap the python code in a try: except SystemExit: as suggested by @fjames above
    • "overwrite" the exit method by for example running the following code after the python engine is initialized: 
    def _exit():
    print("exit prevented")

__builtins__.exit = _exit
import sys
sys.exit = _exit

del(_exit)
    • overwrite the SystemExit exception!

  23. Posted

    1 hour ago, vmishka said:

    I did not add them to Windows 32-bit

    The design time packages are 32-bit so you need to add the paths to the 32-bit target.

     

    The group project contains runtime and designtime packages.

    You first need to compile/build the runtime packages for target 32-bits. Optionally and only if you want to build 64-bit applications with runtime package, build 64-bit runtime packages:

    - Python270.bpl

    - PythonVcl270.bpl

    - PythonFmx270.bpl

    Then install the Design time packages (these are always 32-bits)

    - dclPython270.bpl

    - dclPythonVcl270.bpl

    - dclPythonFmx270.bpl

  24. Posted · Edited by pyscripter

    4 hours ago, Steve Maughan said:

    I made the mistake of updating as soon as it was released. After installing (all default option) I found it had scrubbed my Win64 component path. The Win32 path is in tact but it'll be a right old pain to manually copy between the two. Also had to re-install OnGuard and Konopka components via GetIt (a modest pain).

    I was bitten by this a few times in previous upgrades.  This time I knew better...

×