Problem with DtWsmSetWorkspacesOccupied

[Jolivet]

To change windows occupied workspaces, I use a small program with DtWsmSetWorkspacesOccupied().
The prgram compiled on HPUX 10.20 works on HPUX 10.20.

But the programm compiled on HPUX 11 doesn't work on HPUX 11 !
When calling DtWsmSetWorkspacesOccupied(), a message appears : "Error: Couldn't find per display information", but the DISPLAY is good.

Can you help me ?

Michel

[Anthony Goonetilleke]

This might be a bit obvious but try running xclock to make sure your display env. is set. If this works have a read of the blurb below I found it on the ITRC and thought it might be helpful..

From the standpoint of dtwm, windows can be in 1 of 3 states: - Withdrawn
The window is not under the dtwm's control. This
state is reached when a window is unmapped while
in the currently active workspace, or when the window
is first created but not mapped by the application. - Normal-Unmapped
The window is under dtwm's control and has been
unmapped by dtwm. This occurs when the window is
unmapped due to a workspace switch and the window
does not resided in the new active workspace. - Normal-Mapped
The window is under dtwm's control and is visible in the current workspace.
Note: The terminology Withdrawn, Normal-Unmapped, and Normal-Mapped
are used for the convenience of this explanation and do not
reflect a state that can be found in the source code for
dtwm. Additionally, this explanation is offered for windows
that are not iconified.Switching workspaces--------------------
Normal-Mapped windows are checked to see if you should be visible
in the new workspace. If so, dtwm does nothing and the windows
remain visible. If not, dtwm unmaps the windows and changes your
states to Normal-Unmapped.
Normal-Unmapped windows are checked to see if they should be
visible in the new workspace. If so, they are mapped and their
states are changed to Normal-Mapped. If not, dtwm does nothing
and the windows are not visible.Mapping a window----------------
If a Withdrawn window is mapped by the application, dtwm will check
the workspace in which the window should reside. If the current
workspace is in the window's workspace list, dtwm maps the window
and changes its state to Normal-Mapped. Otherwise, the window is not
mapped and the state is changed to Normal-Unmapped.
If a Normal-Unmapped window is mapped by the application, dtwm does not
check the window's workspace list and assumes that the application
wants the window mapped to the current workspace. It maps the
window and changes its state to Normal-Mapped. This will result
in a window which resides in a different workspace being visible
in the current workspace and the window will exist in bothworkspaces.
Unmapping a window------------------
If a Normal-Mapped window is unmapped by the application, dtwm
unmaps the window and changes its state to Withdrawn.
If a Normal-Unmapped window is unmapped by the application, dtwm
does nothing because it never receives the UnmapNotify event.
This is because the X Protocol defines that unmapping an already
unmapped window results in no action by the Xserver (the window
is already in the desired state). This means that a Normal-Unmapped
window will once again be visible when the user switches to the
workspace that contains that window.
Use XWithdrawWindow to unmap the window. In addition to unmapping
the window, this call sends an UnmapNotify event to the window manager
allowing it to change the windows state to Withdrawn. This call
should only be used against the application's top level windows
(windows that have a window manager frame).

[Alex Glennie]

I'd check you have the correct libs etc installed : do you not need the CDE dev kit etc & Motif dev kits to use DtWsm calls etc ?

Just check on the 10.20 box and see if your missing these first !

[Alex Glennie]

I'd also check the display is definitely set correctly and I'm patched wrt Xserver,CDE & Motif as and Anthony sad there seem a few known issues wrt to this call/routine.