> On 16 Apr 2020, at 14:55, Eko palypse <ekopaly...@gmail.com> wrote: > > Barry, sorry for sending you a private message yesterday, was not intended. > > No, I only have rudimentary knowledge of C++, > but it has been developing since I started using Cython. > I haven't done any stack analysis yet but hey, there's always a first time. > I think my stubbornness could be of help here :-)
Its a very useful when the simple debug stuff fails. > > Visual Studio reports that the last location of the thread is in _ctypes.pyd > and the call stack window shows that the last execution is > user32.dll!InternalDailogBox(). > > Call Stack > > > *user32.dll!InternalDialogBox()user32.dll!DialogBoxIndirectParamAorW()user32.dll!DialogBoxIndirectParamW()_ctypes.pyd!000007fee7fc17e3()_ctypes.pyd!000007fee7fbfee3()_ctypes.pyd!000007fee7fbb4c5()_ctypes.pyd!000007fee7fbc019()_ctypes.pyd!000007fee7fb6dfa()python37.dll!_PyObject_FastCallKeywords(_object > * callable=0x0000000002fa8c78, _object * const * stack=0x0000000005261c78, > __int64 nargs=5, _object * kwnames=0x0000000000000000)* My guess is that you are missing an important parameter to the dialog that allows it be seen. Test the dialog code outside of the embedded python, with a command line python. I recall that you have to pass in the parent for a dialog. Maybe in the embedded version you do not have an HWND that is usable, can NULL be used? Is there a SHOW arg that you need to pass? I'd check the MSDN docs for the call you are making and check every param is as required. (Its been a along time since I did low level win32 in anger so forgive the lack of solutions) > > > The thread is neither suspended nor does it have any different status than > the main thread > which loops through its main event queue at this point. It is suspended inside the user32.dll. Barry > > Thank you > Eren > > > Am Mi., 15. Apr. 2020 um 22:57 Uhr schrieb Barry <ba...@barrys-emacs.org>: > >> >> >>> On 15 Apr 2020, at 21:18, Eko palypse <ekopaly...@gmail.com> wrote: >>> >>> Thank you for your suggestion. I will give it a try. >>> >>>> What is the "stuck" thread doing? waiting for a lock? >>> >>> No, it should open a dialog created with DialogBoxIndirectParamW >>> < >> https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-dialogboxindirectparamw >>> >> >> I assume you are a C++ developer and can look at the stack of the thread. >> What is the thread doing? Is it in python code? Is it in windows code? >> >> Barry >> >>> . >>> >>> Eren >>> >>>> Am Mi., 15. Apr. 2020 um 20:12 Uhr schrieb Barry Scott < >>>> ba...@barrys-emacs.org>: >>>> >>>> >>>> >>>>>> On 15 Apr 2020, at 13:30, Eko palypse <ekopaly...@gmail.com> wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> the following happens on Windows7 x64 and Python37 x64 >>>>> >>>>> I have a plugin DLL for a C++ application in which Python37 is >> embedded. >>>>> The plugin itself works, except when I want to use the threading >> module. >>>>> >>>>> If I start a Python script in my plugin which uses the threading module >>>>> I can verify via ProcessExplorer that the thread is started, >>>>> but it doesn't do anything (??) and the c++ application doesn't really >>>> do anything anymore either. >>>>> >>>>> Only when I stop the C++ Applikation, the thread becomes active for a >>>> short time. >>>>> Verified with logging module over time print-outs. >>>>> >>>>> Apparently I did not understand everything about threads and embedded >>>> python. >>>>> >>>>> Any idea what I'm doing wrong? >>>> >>>> This is what I typically do. >>>> >>>> Make sure that you have installed the Python debug files. >>>> Now you can use the visual C++ debugger to attach to the process and >>>> look at what the threads are doing. >>>> >>>> I always have the python source code on hand to read as well. >>>> >>>> This should give you a clue. >>>> >>>> What is the "stuck" thread doing? waiting for a lock? >>>> >>>> Barry >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> The whole thing is initialized by the DllMain routine. >>>>> >>>>> >>>>> BOOL APIENTRY DllMain( HANDLE hModule, >>>>> DWORD reasonForCall, >>>>> LPVOID /* lpReserved */ ) >>>>> { >>>>> switch ( reasonForCall ) >>>>> { >>>>> case DLL_PROCESS_ATTACH: >>>>> if (!Py_IsInitialized()) >>>>> { >>>>> PyImport_AppendInittab("Npp", &PyInit_Npp); >>>>> Py_InitializeEx(0); >>>>> PyEval_InitThreads(); //<- this shouldn't be needed as I >>>> understand that it is called by Py_InitializeEx anyway >>>>> } >>>>> PyImport_ImportModule("Npp"); >>>>> break; >>>>> case DLL_PROCESS_DETACH: >>>>> Py_Finalize(); >>>>> break; >>>>> >>>>> case DLL_THREAD_ATTACH: >>>>> break; >>>>> >>>>> case DLL_THREAD_DETACH: >>>>> break; >>>>> } >>>>> >>>>> return TRUE; >>>>> } >>>>> >>>>> and the code in the plugin which executes the python scripts is this >>>>> >>>>> cdef void run_code(): >>>>> try: >>>>> global_dict = globals() >>>>> if '__name__' not in global_dict or global_dict['__name__'] != >>>> '__main__': >>>>> global_dict.update({"__name__": "__main__",}) >>>>> exec(compile(editor.getText(), '<string>', 'exec'), global_dict) >>>>> >>>>> except Exception: >>>>> MessageBoxW(nppData._nppHandle, >>>>> traceback.format_exc(), >>>>> 'RUN CODE EXCEPTION', >>>>> 0) >>>>> >>>>> I don't know if this is important, but the DLL is generated by Cython. >>>>> >>>>> Thank you for reading and stay healthy >>>>> >>>>> Eren >>>>> -- >>>>> https://mail.python.org/mailman/listinfo/python-list >>>>> >>>> >>>> >>> -- >>> https://mail.python.org/mailman/listinfo/python-list >>> >> >> > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
