PYSTDREPL PYPTREPL

[CEXT-Dan]

I think it’s really cool, but there are issues

1, does not work in BricsCAD
2, it throws exceptions in AutoCAD when AutoCAD shuts down, I think it's related to item 3.
Exception thrown at 0x00007FFCF7931EA9 (accore.dll) in acad.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
3, exit seems to not restore stdin, stdout, stderr back to AutoCAD. AutoCAD is pretty much unusable afterwards

[CEXT-Dan]

Thinking about this, I don’t think these commands should be loaded by default. At least not in their current form. There are situations where the console won’t exit properly, the user’s only choice is to exit the whole application, potentially losing work.
I think it’s cool, but not ready to be published, for now, if a user wants to take the risk, they can manually load it

[gswifort]

#240
set PYRX_LOAD_REPL=1 to load on startup

[CEXT-Dan]

entsel() and select() should have a document lock ?
actually, it would be better to have a document lock when ever code is executed, if it’s possible.
there's a disposable lock = Ap.AutoDocLock()

[gswifort]

I tried to do this, but it didn't work unless I did it directly from the console. I called the lock e.g. in the runcode method.

[CEXT-Dan]

it does work in BricsCAD, but you have to click on the editor.

[CEXT-Dan]

BricsCAD it appears to be stalled because the console is the foreground window, messages are not passed until the host app is active, it would be cool to be able to activate the app on runcode .

[gswifort]

I don't remember now if I've already mentioned this or if I've missed it somewhere, but generally PYSTDREPL and PYPTREPL seem to work properly now (after the modifications I've made). I use them often and I don't notice the problems you described (I mainly work with PYPTREPL, but PYSTDREPL should work even better).

EDIT:
I don't know about BricsCAD, battle tested on ZWCAD

[CEXT-Dan]

PYPTREPL is really cool, I really like the autocomplete. Though, 50% of the time I hit the close button and it’s an instant shutdown.
If you can get the handle to the window, you can remove that close button, maybe with win32,
https://nitheeshgeorge.wordpress.com/2012/01/04/disabling-close-button-in-a-window-using-mfc/

[gswifort]

I'll try

[CEXT-Dan]

try in [#314] build

[gswifort]

Disabling the close button is great! But Ctrl+Break capture doesn't work for me, what about you?

[CEXT-Dan]

I see, I'll fix that

[CEXT-Dan]

Honestly, I don’t know much about Consoles. I don’t use them often, and I never use them in a CAD context, except for the cad command line, and that’s pretty much to run command and see output. Maybe you can explain a bit on how you’re using it in a CAD context. Is it purely a development tool? Or is this something that can be used in a CAD work environment?

I can run stuff like this, seems to work well on the platforms

a = Ax.AcadApplication()
d = a.activeDocument()
m = d.modelSpace()
m.addLine(Ge.Point3d(0,0,0) , Ge.Point3d(100,100,0))

I feel that Ax calls are pretty safe

Other API calls like Ed.Core.prompt("hello world") Crash AutoCAD

I think we can remove the config restriction if we can get prevent users from closing the application accidentally

Maybe I can add stuff in C++
https://learn.microsoft.com/en-us/windows/console/setconsolectrlhandler

“The system generates CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT signals when the user closes the console, logs off, or shuts down the system so that the process has an opportunity to clean up before termination.”

https://learn.microsoft.com/en-us/windows/console/registering-a-control-handler-function

[CEXT-Dan]

what version of autocad are you using?

[gswifort]

what version of autocad are you using?

2022

[CEXT-Dan]

works in 2022

**********************************************************************
*  Warning: Do not close the console window, this will immediately   *
*  close the host application. First exit the REPL.                  *
**********************************************************************
>>> Ed.Core.prompt("did it work")
5100

[CEXT-Dan]

PYPTREPL and PYSTDREPL behave differently with CTRL+C, we should choose one an fine tune the behavior

EDIT, actually I can block it, but we should still just keep one

[gswifort]

I don't care about PYSTDREPL, I only added it in case there are problems with PYPTREPL (PYSTDREPL has fewer places where it might not work), but so far I have no problems with PYPTREPL.

[gswifort]

It would be ideal if after pressing Ctrl+C / Ctrl+Break the message (in the console) was displayed: "Use quit() to exit". The same could happen after pressing the close button, but then instead of disabling it, you would have to handle its click.

[gswifort]

Ok, I probably know where this is captured. However, you also need to capture Ctrl+C and the Close button.

[CEXT-Dan]

I got this, I'll make a new build for you to test

**********************************************************************
*  Warning: Do not close the console window, this will immediately   *
*  close the host application. First exit the REPL.                  *
**********************************************************************
Python 3.12.10 (tags/v3.12.10:0cc8128, Apr  8 2025, 12:21:36) [MSC v.1943 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
(StdLibRepl)
>>>
Use quit() to exit:
>>>

the new line doesn't work to great with PYPTREPL, I tried all the combinations of \r\n

[gswifort]

Tthis can happen, ptpython strongly adjusts the console behavior to itself.
Perhaps a better solution would be msgbox.

[gswifort]

Works perfectly!

[CEXT-Dan]

we can probably remove load_repl in user config, and the env entry