What seems to be happening is the the routines from the tk dll don't seem
to be getting mapped into the python dll. This although the exports are
correct and the python dll is linked against it. I've done some work with
dlls, but not much, so this seems a mystery to me.
Any suggestions would be greatly appreciated.
As far as the static Tk/Tcl/lxlib stuff. It works well enough to get the
functions and globals mapped in.
>>It seems that the NT stuff uses the main in Python/frozenmain.c
>>instead of config_nt.c
>Nope. It certainly uses config_nt.c
>
>config_nt.c has some #ifdef magic in it. 1/2 of the code is used for
>Python.EXE, and the other 1/2 is used for Python.dll (ie, config_nt.c is
>compiled twice with different macro defs)
Yes, I've stepped through much of this stuff. You are right about the main,
it does use the main from config_nt.c. I had confused myself when walking
through the tkintermodule stuff. It's getprogramname from frozenmain.c
that get's called from tkintermodule. This makes sense since getprogramname
has to be resolved when the dll is built.
>>tkintermodule.c has a problem where it calls getprogramname in
>>Tkinter_Create as a parameter to strrchr. Because of the
>>compilation of config.c into two separate objects, argv0 isn't
>>defined in the scope that Tkinter_Create is calling from, and
>>thus is null. So, it passes a NULL pointer to strchr, which
>>proceeds to "dump core".
>
>Yes - this is an interesting point.
>
>Python.DLL is basically all of Python. Python.exe is largely a stub with
>main(), then calls into the dll. Any other programs that use Python use
>Python.DLL.
>
>This means that getprogramname is not a function of the DLL itself, but
>should be provided by the calling .EXE.
>
>The same thing is true for functions like fatal()/abort() - ideally, the
>calling EXE should define this, rather than Python.DLL.
>
>The only practical way to handle this (to avoid circular dependencies) may
>be to install function handlers - ie, Python.DLL has a default, and the EXE
>can "override" this. As Python stands, it may be possible to perform this
>with the linker, but Im not sure at all.
>
>I'll look into getprogramname, but the general issue may be worth looking
>at?
>
>>I finally managed to get windows to be opened on the screen by
>>adding some initialization routines to PyInit_Tkinter which
>>registered the window classes needed for TkNt with windows (NT).
>
>I take it you are using the standard console version of Python (Python.exe)
>rather than the GUI version Pythonwin.exe?
Yes, I'm using the console version.
>If so, you are probably in for some strife. Having a program with "main()",
>then creating windows may wreak havoc. I think the problem would be in the
>C RTL - depending on the entry point - main() or WinMain(), the RTL will
>init differently.
Actually, this isn't a problem. Tk creates all it's windows internally through
an Xwindows emulator. It uses the win32 stuff, not MFC, so WinMain isn't a
problem.
>If using Pythonwin.exe - this could work. I know almost nothing about Tk.
I'm working on getting it built.
>Does TK create the main application window, or just sub-windows? If the
>former, then you will almost certainly want a new, special .EXE file for the
>Tk version. This would have a WinMain entry point, and have really basic C
>init code, deferring to Python ASAP.
Tk creates all the windows, including the toplevel window.
>>The problem now is that the window sizing is wrong. The windows
>>are as small as they can be, and can't be resized.
>
>Not sure what you mean by this...
All I was getting was a title bar big enough to fit the system menu, the
lower box, and the raise box.
>>Has anyone managed to get Tkinter running under NT before? If
>>so, I could use any suggestions you have.
>I have seen requests for this before, and never an affirmative reply! You
>may be the trail blazer people have been waiting for :-)
>
>Mark.
>
Actually, things are looking much better. I've been able to run several
python/Tk scripts and have them appear, including the wpy demos. There are
still problems, though. I don't have a cursor when I'm in the Tk window, and
when I find a button widget I can't seem to make it work. Same with menus.
The scroll bars seem to work well, though. Unfortunately, I don't have many
straight Tcl/Tk scripts to make sure that the Tk package is working properly.
It seems to be ok, but I haven't been able to verify whether or not it's fully
functional.
thanks,
-brennan