[Keith]

Hi Paco,

I think I've found the problem. The drawing code had some numerical issues with drawing contacts if the pitch of the contacts were less than a MPP segment length.

However, it's hard to test this for all cases. If you have any examples using the existing code that cause incorrect drawing or a crash and can save them to a library, with the log file, then it would greatly help testing.

regards

Keith

[Keith]

Hi Paco,

This is easy to fix. I just released 4.3.45, so it will need to wait until 4.3.46 early next week.

regards

Keith

[Keith]

Latest version is now out, with several bug fixes and enhancements. See the changes file for details.

[Keith]

Hmm, it used to be documented in the reference docs under 'Programming Glade in Python->ui'

Here is what was documented – I'll add it to the next version. Currently there are no wrappers for form generation. I'd need to add these. What sort of dialog widgets would you need? I guess at a minimum QLabel and QLineEdit (see Qt docs for these) plus horizontal/vertical layouts to place these in?

– Keith

cvar.uiptr
A global pointer to the ui class
instanciation in Glade. Use this rather than creating your own ui variable
using ui(). For example:

gui=cvar.uiptr
gui.OpenCellView("default",
"nand", "layout")

Although you can use e.g.
ui().<functionName()>, this will not work for commands like createAction()
which only work with the existing instanciated ui object.

menu = createMenu(const char *name)
Creates a menu called name
in the menu bar.

menu = createMenu(QMenu *menu,
const char *name)
Creates a submenu called name
in menu.

addSeparator(QMenu *menu)
Adds a separator to the menu.

action = createAction(const char
*name, const char *cmd)
Creates an action called
name with a command cmd. The command should be a valid Python
command. An action defines a common command that can be invoked by any or
all of a menu item, a bindkey or a toolbar button.

action = createAction(const char
*name, const char *cmd, QActionGroup *group)
Creates an action called
name with a command cmd that is part of an actionGroup group.
The command should be a valid Python command. An action defines a common command
that can be invoked by any or all of a menu item, a bindkey or a toolbar button.

actionGroup = createActionGroup()
Create an aactionGroup.

createMenuItem(menu, action)
Adds the action to the menu.
The action name will be shown on the menu, along with any key binding defined
for the action.

setBindKey(action, const char
*keysequence)
Sets the bindkey for action.
keysequence can be a key e.g. "k" or a combination e.g. "Ctrl+p",
"Shift+p", "Alt+p"

An example of a python script for
setting up a user-defined menu is as follows

# define some user function
def myFunction() :

print "Hello World!"

gui = cvar.uiptr
menu = gui.createMenu("MyMenu")
action=gui.createAction("MyAction",
"myFunction()")
gui.createMenuItem(menu, action)
gui.setBindKey(action, "!")

[Keith]

This is a bugfix release. Please keep your installation up to date! Thanks.

[Keith]

BTW you *must* have a Python installation on your Windows machine in order for Python to find necessary library files. As above you can download Python 2.7.4 from http://www.python.org.

Your PYTHONPATH environment variable on Windows should look something like this:

C:Python27-x86Lib;C:Python27-x86libs;C:Python27-x86DLLs;%GLADE_HOME%

[Keith]

I've updated the Windows versions of Glade to Python 2.7.4. The DLL's supplied in the distribution have been meticulously checked that they are correct i.e. the 32 bit Glade is supplied with a 32 bit python27.dll and the 64 bit Glade is supplied with a 64 bit DLL.

If you install Python on windows from http://www.python.org, be aware that their Windows installer is broken, at least if you're running Windows 7 with a 64 bit cpu:

1. If you install the x86 (32 bit) version it puts a 32 bit python27.dll into C:windowssystem32 (wrong!) and C:windowssyswow64 (correct)

2. If you try and install the x64 (64 bit) version to a seperate location, it does not change any existing DLLs from step 1, and even if you delete the DLLs it does not install the 64 bit DLL in C:windowssystem32.

3. If you uninstall python from your system, delete any python27.dll files, and then install the x64 version of Python it seems to get it right. But then installing the 32 bit version does not install any 32 bit DLLs, aargh!

[Keith]

I'm occasionally getting bug reports from people using older versions of Glade than the current release. There are several common bugs fixed in recent versions that can cause crashes – so please update when you can. As always, keep a backup of your old version just in case.

[Keith]

That looks fine. It's not the version I ship by default (have not updated to 2.7.4 yet) but it will work. I guess you must have previously installed Python on your system at some stage, or maybe some other app that installs a python dll.

[Keith]

And what do you see in the logfile – something like:

# Python version 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] for win32

?

[Keith]

Hmm, can you start Windows Event Viewer and expand Windows Logs->Application? Then see if there are any events for Glade, if so click on them and they should show some details about the issue.

Also can you confirm you have no C:WindowsSystem32python27.dll or C:WindowssysWOW64python27.dll?

[Keith]

Couple of things that might help debug your windows problem:

1) If there is a missing DLL *that is required*, the program won't start and Windows will pop up a dialog telling you this. So that enables you to tell whether there are any missign DLL's.

2) When Glade starts, the first thing it does after setting up the logfile is to initialise Python using Py_Initialize. If Python fails to initialise, it will exit with no warning.

3) After that, the app window should show itself and messages will start to be written to the logfile. Do you see the app window, even briefly?

4) It may be worth trying to run from a cmd.exe shell to see if you get any output to the console.

5) When you say 'Python27.dll is the correct one' do you mean dependency walker is showing if finding the one in your installation directory?

6) Are you doing anything other than unzipping the downloaded file, and clicking on the Glade icon? I have not heard of this problem from other users, so it must be something peculiar to your setup.

[Keith]

OK, taking a look at the glade.exe built on my machine running Windows 7 (64 bit) with dependency walker, I also get a lot of missing DLLs (API-MS-WIN-*). There is some info on these DLLs here: http://www.nirsoft.net/articles/windows_7_kernel_architecture_changes.html

However, Glade runs just fine without them, as neither it nor the Qt libs call any functions from these DLLs. Dependency Walker doesn't know this alas, so it 'thinks' that it is a problem that they are missing.

I think these 'missing DLL' issues are a red herring, and your problem is that described in post #16 in this thread – i.e. you've got an incorrect python27.dll somewhere on your machine and are not using the python27.dll shipped in the installation directory. Look at which python27.dll you are picking up in dependency walker, and from where. If it's not from your Glade installation directory, then it's probably not the one you want…

[Keith]

Glade is built on a PC running Windows 7 – so I'll take a look and see if I have those DLLs on my machine. Will probably not be able to until later today though.

[Keith]

Normally you just have to install the runtime libraries, the Microsoft installer for these is provided in the distribution.

The DLLs you mention are not those however, they are core Windows API DLLs.

Are you running the 32 or 64 bit version?

[Author]

Posts