f

#### Setting VIO window title text

Is there any way a VIO application can set the text on the VIO
title bar?

I have the various toolkit INF files, but it's not obvious which
one to search.  I'm guessing that it needs to be a PM function,
but that only raises the question of how the VIO application can
find the right window handle.

--
Peter Moylan                            Peter.Moylan@newcastle.edu.au
http://eepjm.newcastle.edu.au (OS/2 and eCS information and software)

 0
peter
2/12/2004 5:28:00 AM
comp.os.os2.programmer.misc 1326 articles. 0 followers.

32 Replies
806 Views

Similar Articles

[PageSpeed] 16

[A complimentary Cc of this posting was sent to
Peter Moylan
<peter@totally-official.com>], who wrote in article <slrnc2m3n2.12j.peter@eepjm.newcastle.edu.au>:
> Is there any way a VIO application can set the text on the VIO
> title bar?

There is a documented way (DOSSMSETTITLE, which "usually" fails), and
a hack (which everybody uses).

> I have the various toolkit INF files, but it's not obvious which
> one to search.  I'm guessing that it needs to be a PM function,

WinSetWindowText() (sp?) is fine.

> but that only raises the question of how the VIO application can
> find the right window handle.

No problem whatsoever.  Here is how Perl does it (a lot of verbiage to
avoid linking PM DLLs, run under DOS, have meaningful and complete
error handling etc):

static HSWITCH
switch_of(HWND hwnd, PID pid)
{
HSWITCH hSwitch;

if (!(_emx_env & 0x200))
croak("switch_entry not implemented on DOS"); /* not OS/2. */
if (CheckWinError(hSwitch =
myWinQuerySwitchHandle(hwnd, pid)))
croak_with_os2error("WinQuerySwitchHandle");
return hSwitch;
}

static void
fill_swentry(SWENTRY *swentryp, HWND hwnd, PID pid)
{
int rc;
HSWITCH hSwitch = switch_of(hwnd, pid);

swentryp->hswitch = hSwitch;
if (CheckOSError(myWinQuerySwitchEntry(hSwitch, &swentryp->swctl)))
croak_with_os2error("WinQuerySwitchEntry");
}

static void
fill_swentry_default(SWENTRY *swentryp)
{
fill_swentry(swentryp, NULLHANDLE, getpid());
}

Now after fill_swentry_default(&swentry) you can access swentry.hwnd.

Hope this helps,
Ilya

 0
Ilya
2/12/2004 7:03:13 AM
Here in comp.os.os2.programmer.misc,
peter@seagoon.newcastle.edu.au (Peter Moylan) spake unto us, saying:

>Is there any way a VIO application can set the text on the VIO
>title bar?

The 4OS2 shell can do that via the TITLE command, so it must be
possible.  :-)

--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) seeking employment.
See web site above for resume/CV and background.

 0
rsteiner
2/12/2004 8:49:39 AM
On 12 Feb 2004 05:28:00 GMT, Peter Moylan <peter@seagoon.newcastle.edu.au>
wrote:

> Is there any way a VIO application can set the text on the VIO
> title bar?

WinSetTitle or
WinQuerySwitchHandle / WinQuerySwitchEntry / WinChangeSwitchEntry

> I have the various toolkit INF files, but it's not obvious which
> one to search.  I'm guessing that it needs to be a PM function,
> but that only raises the question of how the VIO application can
> find the right window handle.

WinSetTitle doesn't need a handle.
WinQuerySwitchHandle can use a PID.

 0
Paul
2/12/2004 1:13:31 PM
[A complimentary Cc of this posting was sent to
Richard Steiner
<rsteiner@visi.com>], who wrote in article <j4zKApHpvKvE092yn@visi.com>:
> Here in comp.os.os2.programmer.misc,
> peter@seagoon.newcastle.edu.au (Peter Moylan) spake unto us, saying:
>
> >Is there any way a VIO application can set the text on the VIO
> >title bar?
>
> The 4OS2 shell can do that via the TITLE command, so it must be
> possible.  :-)

Since this command does not work in most situations, this is hardly
relevant.  Compare

start /fg
window "abc"			(in the new session)

with

start "random name" /fg
window "abc"			(in the new session)

Hope this helps,
Ilya


 0
Ilya
2/12/2004 4:48:34 PM
Here in comp.os.os2.programmer.misc,
Ilya Zakharevich <nospam-abuse@ilyaz.org> spake unto us, saying:

><rsteiner@visi.com>], who wrote in article <j4zKApHpvKvE092yn@visi.com>:
>
>> The 4OS2 shell can do that via the TITLE command, so it must be
>> possible.  :-)
>
>Since this command does not work in most situations, this is hardly
>relevant.  Compare
>
>  start /fg
>  window "abc"			(in the new session)
>
>with
>
>  start "random name" /fg
>  window "abc"			(in the new session)

Both of the above work as expected here (and also when explicitly using
the TITLE command as I stated).

--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) seeking employment.
See web site above for resume/CV and background.

 0
rsteiner
2/12/2004 10:31:40 PM
On Thu, 12 Feb 2004 13:13:31 UTC, Paul Ratcliffe
<abuse@orac12.clara34.co56.uk78> wrote:

> On 12 Feb 2004 05:28:00 GMT, Peter Moylan <peter@seagoon.newcastle.edu.au>
> wrote:
>
> > Is there any way a VIO application can set the text on the VIO
> > title bar?
>
> WinSetTitle or
> WinQuerySwitchHandle / WinQuerySwitchEntry / WinChangeSwitchEntry
>
> > I have the various toolkit INF files, but it's not obvious which
> > one to search.  I'm guessing that it needs to be a PM function,
> > but that only raises the question of how the VIO application can
> > find the right window handle.
>
> WinSetTitle doesn't need a handle.
> WinQuerySwitchHandle can use a PID.

I can confirm the above calls. But...

Be aware, that WinSetTitle and (an alternative) WinSetTitleAndIcon are
NOT defined in any of the toolkit headers that I have  - latest is 4.51.
Also, I believe them to be 16-bit functions, and you will need to
prototype them appropriately e.g.

APIRET16 APIENTRY16 WinSetTitleAndIcon(PSZ pszTitle, PSZ pszIcon)

--
Regards, Mike Fry
email: mikefry@iafrica.com


 0
Mike
2/12/2004 11:16:16 PM
On 13 Feb 2004 01:16:16 +0200, Mike Fry <xxx-mikefry-xxx@xxx-iafrica.com>
wrote:

> Be aware, that WinSetTitle and (an alternative) WinSetTitleAndIcon are
> NOT defined in any of the toolkit headers that I have  - latest is 4.51.
> Also, I believe them to be 16-bit functions, and you will need to
> prototype them appropriately e.g.
>
> APIRET16 APIENTRY16 WinSetTitleAndIcon(PSZ pszTitle, PSZ pszIcon)

Agreed. Just for completeness:
APIRET16 APIENTRY16 WinSetTitle(PSZ pszTitle)

You may also need to specify the entrypoints in the .DEF file:
IMPORTS
WinSetTitle = PMSHAPI.93
WinSetTitleAndIcon = PMSHAPI.97

 0
Paul
2/13/2004 1:11:59 AM
[A complimentary Cc of this posting was sent to
Richard Steiner
<rsteiner@visi.com>], who wrote in article <M7/KApHpvKIa092yn@visi.com>:
> >Since this command does not work in most situations, this is hardly
> >relevant.  Compare
> >
> >  start /fg
> >  window "abc"			(in the new session)
> >
> >with
> >
> >  start "random name" /fg
> >  window "abc"			(in the new session)
>
> Both of the above work as expected here (and also when explicitly using
> the TITLE command as I stated).

Not in my very old version (which has no TITLE command, btw).  This
means that they do not use the SM API, but modify the window title
directly...

Hope this helps,
Ilya

 0
Ilya
2/13/2004 9:59:05 AM
Here in comp.os.os2.programmer.misc,
Ilya Zakharevich <nospam-abuse@ilyaz.org> spake unto us, saying:

>Richard Steiner <rsteiner@visi.com>] wrote
>
>> Both of the above work as expected here (and also when explicitly using
>> the TITLE command as I stated).
>
>Not in my very old version (which has no TITLE command, btw).  This
>means that they do not use the SM API, but modify the window title
>directly...

You should consider updating, since 4OS2 is now freeware.  The version
I'm using (for reference) is this one:

4OS2 3.04E   OS/2 Version is 4.50
4OS2 Revision E (156)   OS/2 Revision A
Copyright (c) 1988-2002 JP Software, Inc -- http://jpsoft.com/
SciTech Edition -- not supported by JP Software, Inc.
Built with Open Watcom C/C++ -- http://www.openwatcom.org/

which can be obtained here:

http://www.scitechsoft.com/ftp/devel/beta/4os2304e.zip

A slightly older version of the source (for reference) can be found
here:

http://hobbes.nmsu.edu/pub/os2/util/shell/4os2src.zip

--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + eCS + Linux + Win95 + DOS + PC/GEOS + Executor = PC Hobbyist Heaven!
Applications analyst/designer/developer (14 yrs) seeking employment.
See web site above for resume/CV and background.

 0
rsteiner
2/13/2004 10:47:55 AM
 Ilya Zakharevich infrared:
>[A complimentary Cc of this posting was sent to
>Peter Moylan
><peter@totally-official.com>], who wrote in article <slrnc2m3n2.12j.peter@eepjm.newcastle.edu.au>:
>> Is there any way a VIO application can set the text on the VIO
>> title bar?

Thanks to everyone who responded.  I don't yet have a working
solution, but at least I'm getting to understand why it's difficult.

>There is a documented way (DOSSMSETTITLE, which "usually" fails), and
>a hack (which everybody uses).
>
>> I have the various toolkit INF files, but it's not obvious which
>> one to search.  I'm guessing that it needs to be a PM function,
>
>WinSetWindowText() (sp?) is fine.

The catch is that this one requires a message queue - see below.

>> but that only raises the question of how the VIO application can
>> find the right window handle.
>
>No problem whatsoever.

[snip detail]

>Now after fill_swentry_default(&swentry) you can access swentry.hwnd.

Actually it's swentry.swctl.hwnd, but that change was obvious after
looking at the definitions.  OK, I now have a plausible-looking
window handle.  (My software doesn't include getpid(), but
DosGetInfoBlocks does just as well.)  After that, I discovered that
the real problem isn't getting the handle, it's trying to use it.

If I build my program as a VIO application, WinSetWindowText fails
because there's no message queue.

If I add WinInitialize and WinCreateMsgQueue, WinCreateMsgQueue
fails with an error code that says that this is not a PM application.

If I relink it as a PM application, WinCreateMsgQueue is now OK
but the application is useless because the VIO window disappears
from the screen.

I've tried playing around with WinChangeSwitchEntry to pretend that
I'm temporarily a PM application while setting the title, but
the system doesn't let me get away with that; WinCreateMsgQueue
still fails.

So, at least for now, I'm stuck.

--
Peter Moylan                            Peter.Moylan@newcastle.edu.au
http://eepjm.newcastle.edu.au (OS/2 and eCS information and software)

 0
peter
2/16/2004 2:47:50 AM
Paul Ratcliffe infrared:
>On 12 Feb 2004 05:28:00 GMT, Peter Moylan <peter@seagoon.newcastle.edu.au>
>wrote:
>
>> Is there any way a VIO application can set the text on the VIO
>> title bar?
>
>WinSetTitle or
>WinQuerySwitchHandle / WinQuerySwitchEntry / WinChangeSwitchEntry

I've experimented with the second of these.  It turns out that
WinChangeSwitchEntry does change the title in the window list
(the thing that comes up with Ctrl/Esc), but it doesn't change the
title bar of the VIO application.

>> I have the various toolkit INF files, but it's not obvious which
>> one to search.  I'm guessing that it needs to be a PM function,
>> but that only raises the question of how the VIO application can
>> find the right window handle.
>
>WinSetTitle doesn't need a handle.

This sounds like a solution, but it might take me along a
time-consuming sidetrack.  The software in question is written in
Modula-2, and I've never worked out in M2 how to thunk to a
16-bit library function.  Presumably I can track down documentation
that says how to do it in C, then visualize what that means
in assembly language and then translate that to M2, but to be
honest that sounds as if it will take more time than I want to
put into this job.

My only reason for wanting to change the title bar was to put
some information there that was taking up valuable space in the
VIO window.  If the job is too complex, I'm better off leaving
that information in the main window.

--
Peter Moylan                            Peter.Moylan@newcastle.edu.au
http://eepjm.newcastle.edu.au (OS/2 and eCS information and software)

 0
peter
2/16/2004 3:00:04 AM
 > If I build my program as a VIO application, WinSetWindowText fails
> because there's no message queue.

> If I add WinInitialize and WinCreateMsgQueue, WinCreateMsgQueue
> fails with an error code that says that this is not a PM application.

Give DosGetInfoBlocks()'s pib_ultype a value of 3 to pretend being a PM app.
Not required, but restore pib_ultype to the original value when you're done.

---

 0
spamgate
2/16/2004 3:52:56 AM
M1 infrared:
>
> > If I build my program as a VIO application, WinSetWindowText fails
> > because there's no message queue.
>
> > If I add WinInitialize and WinCreateMsgQueue, WinCreateMsgQueue
> > fails with an error code that says that this is not a PM application.
>
>Give DosGetInfoBlocks()'s pib_ultype a value of 3 to pretend being a PM app.
>Not required, but restore pib_ultype to the original value when you're done.

That did it!  Thank you.

--
Peter Moylan                            Peter.Moylan@newcastle.edu.au
http://eepjm.newcastle.edu.au (OS/2 and eCS information and software)

 0
peter
2/16/2004 5:42:01 AM
In <c0pb0m$e7s$1@seagoon.newcastle.edu.au>, on 02/16/2004
at 02:47 AM, peter@seagoon.newcastle.edu.au (Peter Moylan) said:

>If I build my program as a VIO application, WinSetWindowText fails
>because there's no message queue.

You need to temporarily morph to PM app.  Google for "morph PM OS/2" for
sample code.  Lots of apps do this.

Regards,

Steven

--
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 2.41 #10183
Warp4/FP15/14.093c_W4 www.scoug.com irc.webbnet.info irc.fyrelizard.org #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------


 0
Steven
2/16/2004 6:56:29 AM
Peter Moylan wrote:

> >Give DosGetInfoBlocks()'s pib_ultype a value of 3 to pretend being a PM app.
> >Not required, but restore pib_ultype to the original value when you're done.
>
> That did it!  Thank you.

If it is an application that should run in TShell/floppy boot
mode then You should check the result of Dos16SMPPMresent
(doscalls.712,16 Bit..) or at least do not use it
if session type is fullscreen:

DosGetInfoBlocks(TB, PB);
if PB^.Pib_ulType<>0...

--
Veit Kannegieser

 0
Veit
2/16/2004 9:39:15 AM
Veit Kannegieser infrared:
>Peter Moylan wrote:
>
>> >Give DosGetInfoBlocks()'s pib_ultype a value of 3 to pretend being a PM app.
>> >Not required, but restore pib_ultype to the original value when you're done.
>>
>> That did it!  Thank you.
>
>If it is an application that should run in TShell/floppy boot
>mode then You should check the result of Dos16SMPPMresent
>(doscalls.712,16 Bit..) or at least do not use it
>if session type is fullscreen:
>
> DosGetInfoBlocks(TB, PB);
> if PB^.Pib_ulType<>0...

That's not an issue in my case, but I guess it will help other people.

In case anyone is interested, my final solution is reproduced below.
(The code is in Modula-2, but it would be almost identical in any
other language.)  The interesting thing is that the morphing to a
PM program is needed ONLY for creating the message queue, and
therefore all the hard work is in the initialisation code.  Once the
message queue is created and the window handle identified, the
VIO program can call SetOurTitle as many times as it likes, without
having to pretend that it's a PM program.

IMPLEMENTATION MODULE VIOTitle;

(********************************************************)
(*                                                      *)
(*         Manipulation of a VIO window title           *)
(*                                                      *)
(*         Based on code from Ilya Zakharevich          *)
(*                                                      *)
(*  Programmer:         P. Moylan                       *)
(*  Started:            13 February 2004                *)
(*  Last edited:        16 February 2004                *)
(*  Status:             Working                         *)
(*                                                      *)
(*  Technique:                                          *)
(*     We can use WinSetWindowText to set the title,    *)
(*     but that requires a PM program to create a       *)
(*     message queue.  By setting the pib_ultype field  *)
(*     of the PIB we trick the system into thinking     *)
(*     we are a PM program at the times we want to do   *)
(*     PM operations.                                   *)
(*                                                      *)
(*     It turns out that this trick is needed only      *)
(*     when creating the message queue.  Furthermore,   *)
(*     the data we need remain constant for the         *)
(*     lifetime of the program, so we can put           *)
(*     essentially all of the work into the module      *)
(*     initialisation and finalisation code, and        *)
(*     then use the same window handle to change the    *)
(*     title as often as we like.                       *)
(*                                                      *)
(*     Note that there's no error checking.  If the     *)
(*     operation fails, there's not much we can do      *)
(*     about it anyway, and it's a nonfatal error.      *)
(*                                                      *)
(********************************************************)

IMPORT OS2;

(************************************************************************)

VAR
(* Our window handle. *)

OurHwnd: OS2.HWND;

(************************************************************************)

PROCEDURE SetOurTitle (newtitle: ARRAY OF CHAR);

(* Sets the text on the title bar of the current program. *)

BEGIN
OS2.WinSetWindowText (OurHwnd, newtitle);
END SetOurTitle;

(************************************************************************)
(*                        MODULE INITIALISATION                         *)
(************************************************************************)

VAR oldultype: CARDINAL;
hSwitch: OS2.HSWITCH;
SwitchData: OS2.SWCNTRL;
hab : OS2.HAB;   hmq : OS2.HMQ;
pPib: OS2.PPIB;  pTib: OS2.PTIB;

BEGIN
(* This code is executed on program startup. *)

OS2.DosGetInfoBlocks (pTib, pPib);
oldultype := pPib^.pib_ultype;
pPib^.pib_ultype := 3;
hab := OS2.WinInitialize(0);
hmq := OS2.WinCreateMsgQueue (hab, 0);
hSwitch := OS2.WinQuerySwitchHandle (OS2.NULLHANDLE, pPib^.pib_ulpid);
OS2.WinQuerySwitchEntry (hSwitch, SwitchData);
OurHwnd := SwitchData.hwnd;
pPib^.pib_ultype := oldultype;

FINALLY

(* This code is executed during program termination. *)

oldultype := pPib^.pib_ultype;
pPib^.pib_ultype := 3;
OS2.WinDestroyMsgQueue(hmq);
OS2.WinTerminate(hab);
pPib^.pib_ultype := oldultype;

END VIOTitle.

--
Peter Moylan                            Peter.Moylan@newcastle.edu.au
http://eepjm.newcastle.edu.au (OS/2 and eCS information and software)

 0
peter
2/17/2004 2:34:52 AM
On 17 Feb 2004 02:34:52 GMT, Peter Moylan wrote:

<snip>

You're creating a msg queue pretending to be a PM program. When you exit,
you're not pretending to be a PM program. I assume OS/2 is smart enough to
clean up the msg queue, but to make sure, have you tried calling a test
program with this technique (which exits immediately) a large number of times
to see if there are leaks?

Mat Nieuwenhoven


 0
Mat
2/17/2004 5:13:37 AM
Mat Nieuwenhoven infrared:
>On 17 Feb 2004 02:34:52 GMT, Peter Moylan wrote:
>
><snip>
>
>You're creating a msg queue pretending to be a PM program. When you exit,
>you're not pretending to be a PM program. I assume OS/2 is smart enough to
>clean up the msg queue, but to make sure, have you tried calling a test
>program with this technique (which exits immediately) a large number of times
>to see if there are leaks?

I haven't done this test, but I would expect that WinDestroyMsgQueue
would do the cleanup.  Note that I again switch back to pretending to
be a PM program before calling WinDestroyMsgQueue, so it shouldn't
be any different from the way a PM program terminates.

When you say that my code exits immediately, you might be assuming
that the code I showed is the entire program.  It's not, it's only
one module, which provides a single procedure that can be called
many times from other modules.  There's only one message queue,
which exists for the lifetime of the program.  The code that comes
after the keyword FINALLY is not executed until the program terminates,
at which time all modules execute their finalisation code, in top-down
order.

--
Peter Moylan                            Peter.Moylan@newcastle.edu.au
http://eepjm.newcastle.edu.au (OS/2 and eCS information and software)

 0
peter
2/17/2004 6:09:18 AM
[A complimentary Cc of this posting was sent to
Veit Kannegieser
<Veit.Kannegieser@gmx.de>], who wrote in article <QDILePYdqOVx-pn2-DdQWn4dLNKTT@ID-48912.user.individual.de>:
> > >Give DosGetInfoBlocks()'s pib_ultype a value of 3 to pretend being a PM app.

> If it is an application that should run in TShell/floppy boot
> mode then You should check the result of Dos16SMPPMresent
> (doscalls.712,16 Bit..) or at least do not use it
> if session type is fullscreen:
>
>  DosGetInfoBlocks(TB, PB);
>  if PB^.Pib_ulType<>0...

Do you think this is better than what Perl borrowed from fed:

/* The module will not function well without PM.
The usual way to detect PM is the existence of the mutex
\SEM32\PMDRAG.SEM. */
HMTX hMtx = 0;

if (CheckOSError(DosOpenMutexSem("\\SEM32\\PMDRAG.SEM",
&hMtx)))
Perl_croak_nocontext("Looks like we have no PM; will not load DLL %s without $ENV{PERL_ASIF_PM}", loadOrdinals[ord].dll->modname); DosCloseMutexSem(hMtx); Thanks, Ilya   0 Ilya 2/17/2004 9:20:38 AM [A complimentary Cc of this posting was sent to Peter Moylan <peter@totally-official.com>], who wrote in article <c0pbnk$e7s$2@seagoon.newcastle.edu.au>: > >> Is there any way a VIO application can set the text on the VIO > >> title bar? > > > >WinSetTitle or > >WinQuerySwitchHandle / WinQuerySwitchEntry / WinChangeSwitchEntry > > I've experimented with the second of these. It turns out that > WinChangeSwitchEntry does change the title in the window list > (the thing that comes up with Ctrl/Esc), but it doesn't change the > title bar of the VIO application. Right. BTW, if one *wants* to find all these gory details, recent Perls have all 3 semantics available: a change via the SM API, via ChangeSwitchEntry, and via SetWindowText (as well as higher-level calls which do "the best"). And while many newest additions are not documented, these are fully documented; use, e.g., view perl Title_set Hope this helps, Ilya   0 Ilya 2/17/2004 9:27:59 AM On Tue, 17 Feb 2004 06:09:18 UTC, peter@seagoon.newcastle.edu.au (Peter Moylan) wrote: > Mat Nieuwenhoven infrared: > >On 17 Feb 2004 02:34:52 GMT, Peter Moylan wrote: > > > >You're creating a msg queue pretending to be a PM program. When you exit, > >you're not pretending to be a PM program. I assume OS/2 is smart enough to > >clean up the msg queue, but to make sure, have you tried calling a test > >program with this technique (which exits immediately) a large number of times > >to see if there are leaks? > > I haven't done this test, but I would expect that WinDestroyMsgQueue > would do the cleanup. Note that I again switch back to pretending to > be a PM program before calling WinDestroyMsgQueue, so it shouldn't > be any different from the way a PM program terminates. I wouldn't be worried about leaks. Rather, I'd be concerned about shutdown. Try shutting down the system while your program is still running. Chances are that shutdown will fail the first time. At shutdown, PM posts a WM_QUIT to each queue and won't proceed until each queue has processed it. If you create a msg queue that you don't plan to service, you should call WinCancelShutdown( hmq, TRUE) immediately after creating the queue. This will prevent WM_QUIT from ever being posted to it and gumming up the works. -- == == almost usable email address: DragText AT E-vertise.Com == == ___________________________________________________________________ | DragText v3.8 Rich Walsh | A Distinctly Different Desktop Enhancement Ft Myers, FL | http://e-vertise.com/dragtext/ ___________________________________________________________________   0 Rich 2/17/2004 8:31:38 PM Ilya Zakharevich wrote: > Do you think this is better than what Perl borrowed from fed: > if (CheckOSError(DosOpenMutexSem("\\SEM32\\PMDRAG.SEM", Best should really try to DosQueryProcAddr for doscalls.712 and call that.. Veit Kannegieser   0 Veit 2/17/2004 9:19:09 PM [A complimentary Cc of this posting was sent to Veit Kannegieser <Veit.Kannegieser@gmx.de>], who wrote in article <QDILePYdqOVx-pn2-s9OdtdefhYdg@ID-48912.user.individual.de>: > > Do you think this is better than what Perl borrowed from fed: > > > if (CheckOSError(DosOpenMutexSem("\\SEM32\\PMDRAG.SEM", > Best should really try to DosQueryProcAddr for doscalls.712 and call > that.. But *why* you think this is better? E.g, is SM always loaded? BTW, when I tried to use DOSSMSETTITLE() or Win16SetTitle() from perl with dynamic resolution of addresses, I never succeeded. The same code with static function works; *and* the address returned from DosQueryProcAddr() is different than the statically linked address... BTW, the #ifdef'ed code is /* static ULONG (* APIENTRY16 pDosSmSetTitle)(ULONG, PSZ); */ ULONG _THUNK_FUNCTION(DosSmSetTitle)(ULONG, PSZ); #if 0 /* Does not work. */ static ULONG (*pDosSmSetTitle)(ULONG, PSZ); static void sesmgr_title_set(char *s) { SWENTRY swentry; static HMODULE hdosc = 0; BYTE buf[20]; long rc; fill_swentry_default(&swentry); if (!pDosSmSetTitle || !hdosc) { if (CheckOSError(DosLoadModule(buf, sizeof buf, "sesmgr", &hdosc))) croak("Cannot load SESMGR: no %s'", buf); if (CheckOSError(DosQueryProcAddr(hdosc, 0, "DOSSMSETTITLE", (PFN*)&pDosSmSetTitle))) croak("Cannot load SESMGR.DOSSMSETTITLE, err=%ld", rc); } /* (pDosSmSetTitle)(swcntrl.idSession,s); */ rc = ((USHORT) (_THUNK_PROLOG (2+4); _THUNK_SHORT (swcntrl.idSession); _THUNK_FLAT (s); _THUNK_CALLI (*pDosSmSetTitle))); if (CheckOSError(rc)) warn("*DOSSMSETTITLE: err=%ld, ses=%ld, addr=%x, *paddr=%x", rc, swcntrl.idSession, &_THUNK_FUNCTION(DosSmSetTitle), pDosSmSetTitle); } #else /* !0 */ Thanks, Ilya   0 Ilya 2/17/2004 9:41:41 PM Ilya Zakharevich wrote: > But *why* you think this is better? E.g, is SM always loaded? Surely not, but the doscall1.dll code is not using it: ; ; External Entry #712 into the Module doscall1 ; Attributes: 286-gate Exported DOSSMPMPRESENT proc far arg_0 = dword ptr 6 enter 0, 0 push ds push di mov ax, seg dseg05 mov ds, ax assume ds:dseg05 mov al, PM_Present cbw lds di, [bp+arg_0] assume ds:dseg06 mov [di], ax xor ax, ax pop di pop ds leave retf 4 DOSSMPMPRESENT endp > BTW, when I tried to use DOSSMSETTITLE() or Win16SetTitle() from perl > with dynamic resolution of addresses, I never succeeded. The same > code with static function works; *and* the address returned from > DosQueryProcAddr() is different than the statically linked address... No idea, but then surely your dynamic load code has a flaw ;) -- Veit   0 Veit 2/17/2004 10:31:15 PM Rich Walsh infrared: >On Tue, 17 Feb 2004 06:09:18 UTC, peter@seagoon.newcastle.edu.au (Peter Moylan) >wrote: >> Mat Nieuwenhoven infrared: >> >On 17 Feb 2004 02:34:52 GMT, Peter Moylan wrote: >> > >> >You're creating a msg queue pretending to be a PM program. When you exit, >> >you're not pretending to be a PM program. I assume OS/2 is smart enough to >> >clean up the msg queue, but to make sure, have you tried calling a test >> >program with this technique (which exits immediately) a large number of times >> >to see if there are leaks? >> >> I haven't done this test, but I would expect that WinDestroyMsgQueue >> would do the cleanup. Note that I again switch back to pretending to >> be a PM program before calling WinDestroyMsgQueue, so it shouldn't >> be any different from the way a PM program terminates. > >I wouldn't be worried about leaks. Rather, I'd be concerned about >shutdown. Try shutting down the system while your program is still >running. Chances are that shutdown will fail the first time. At >shutdown, PM posts a WM_QUIT to each queue and won't proceed until >each queue has processed it. If you create a msg queue that you >don't plan to service, you should call WinCancelShutdown( hmq, TRUE) >immediately after creating the queue. This will prevent WM_QUIT from >ever being posted to it and gumming up the works. Thanks, Rich. I've added this, just to be on the safe side. Apart from the shutdown, my impression was that this message queue wasn't going to get many messages anyway. If you consider that a VIO window (which isn't a full-screen session) is itself a PM application, there must be an external queue which is managed by whatever piece of software creates VIO sessions, and which is intercepting the window messages. (If my queue were hanging onto them, I wouldn't be able to do things like move or resize the VIO window.) This impression is reinforced by the observation that I can change the window title multiple times. Each call to WinSetWindowText sends a WM_SETWINDOWPARAMS message, and if there was intermediate crud blocking up the queue then the second such message would remain stuck on the queue. (Or do I have this wrong? Perhaps there is some queue-jumping.) From this I deduce that there is either no intermediate crud, or that all the messages are being bumped up to the parent (or the owner of the VIO process) for action. In fact someone must be handling that WM_SETWINDOWPARAMS message, and it's not me because I haven't created a window procedure. -- Peter Moylan Peter.Moylan@newcastle.edu.au http://eepjm.newcastle.edu.au (OS/2 and eCS information and software)   0 peter 2/18/2004 2:24:32 AM On Wed, 18 Feb 2004 02:24:32 UTC, peter@seagoon.newcastle.edu.au (Peter Moylan) wrote: > > Apart from the shutdown, my impression was that this message queue > wasn't going to get many messages anyway. If you consider that > a VIO window (which isn't a full-screen session) is itself a PM > application, there must be an external queue which is managed by > whatever piece of software creates VIO sessions, and which is > intercepting the window messages. (If my queue were hanging onto > them, I wouldn't be able to do things like move or resize the > VIO window.) AFAIK, the only msg your queue would ever get is WM_QUIT, and using WinCancelShutdown() prevents that. The only reason you need this queue at all is to provide a mechanism for sending a msg to another thread. In this case, that thread is the shell process's primary thread (i.e. the first thread of pmshell #1) which owns & operates all VIO windows. -- == == almost usable email address: DragText AT E-vertise.Com == == ___________________________________________________________________ | DragText v3.8 Rich Walsh | A Distinctly Different Desktop Enhancement Ft Myers, FL | http://e-vertise.com/dragtext/ ___________________________________________________________________   0 Rich 2/18/2004 6:25:24 AM On Tue, 17 Feb 2004 21:19:09 UTC, "Veit Kannegieser" <Veit.Kannegieser@gmx.de> wrote: > Best should really try to DosQueryProcAddr for doscalls.712 > and call that.. Once there was a file on the net named OS2UNDOC.INF. I'm asking myself, if the creator of this file, Rick Papo, rpapo at msen dot com is still around. For me it sounds like a good idea to add information like this. -- Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany] http://www.s-t.de Please remove all characters left of the "R" in my email address   0 Ruediger 2/18/2004 7:19:14 AM On Tue, 17 Feb 2004 22:31:15 UTC, "Veit Kannegieser" <Veit.Kannegieser@gmx.de> wrote: > No idea, but then surely your dynamic load code has a flaw ;) The most common problem with dynamic loading of 16 bit functions is, that DosQueryProcAddr() will return a flat address, no matter if the imported function resides in 16 or 32 code. Some compilers can do the neccessary address conversion automatically. I.e they recognize the situation, that a function expects the (flat) address of a flat pointer and the caller has passed in the (flat) address of a 16:16 pointer. But AFAIK, only ICC has this feature. -- Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany] http://www.s-t.de Please remove all characters left of the "R" in my email address   0 Ruediger 2/18/2004 8:52:17 AM On Wed, 18 Feb 2004 08:52:17 UTC, "Ruediger Ihle" <NO_SPAM_R.Ihle@S-t.De> wrote: > But AFAIK, only ICC has this feature. I have to correct myself: ICC keeps the flat pointer in memery and does the address conversion every time the function is called. BTW, the prototype for DosSmSetTitle appears to be: APIRET16 APIENTRY16 DosSmSetTitle)(PSZ pszTitle); It return 0 on success or error 372, if one messes up the API (which seems to be possible by specifying an invalid title pointer). This works for here: #define INCL_BASE #include <os2.h> #include <stdio.h> #if defined __BORLANDC__ typedef APIRET16 APIENTRY16 (* PDOSSMSETTITLE)(PSZ16 pszTitle); #elif defined __IBMC__ typedef APIRET16 (* APIENTRY16 PDOSSMSETTITLE)(PSZ pszTitle); #else #error "go figure !" #endif int main(void) { ULONG rc; HMODULE hMod; PFN pfnTemp; PDOSSMSETTITLE pDosSmSetTitle; if( DosLoadModule(NULL, 0, "SESMGR", &hMod) == 0 && DosQueryProcAddr(hMod, 0, "DOSSMSETTITLE", &pfnTemp) == 0 ) { pDosSmSetTitle = (PDOSSMSETTITLE)pfnTemp; printf("%08lx %08lx\n", pfnTemp, pDosSmSetTitle); getchar(); rc = (*pDosSmSetTitle)("1234"); printf("Title changed. (%d, %08lx)\n", rc, rc); getchar(); } return 0; } -- Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany] http://www.s-t.de Please remove all characters left of the "R" in my email address   0 Ruediger 2/18/2004 12:21:32 PM Servus Ruediger! RI> From: "Ruediger Ihle" <NO_SPAM_R.Ihle@S-t.De> RI> BTW, the prototype for DosSmSetTitle appears to be: RI> APIRET16 APIENTRY16 DosSmSetTitle)(PSZ pszTitle); RI> It return 0 on success or error 372, if one messes up RI> the API (which seems to be possible by specifying an RI> invalid title pointer). And what's about this: 372 ERROR_SMG_SET_TITLE Title sent by shell or parent cannot be changed. Herzliche Gruesse, Harald -+- Message created on Thursday February, 19 2004 09:22:30 MEZ   0 Harald 2/19/2004 8:18:48 AM On Fri, 13 Feb 2004 10:47:55 UTC, rsteiner@visi.com (Richard Steiner) wrote: > A slightly older version of the source (for reference) can be found > here: > > http://hobbes.nmsu.edu/pub/os2/util/shell/4os2src.zip > That source works! I've tried it! See module os2calls.c & os2init.c, but beware of the comments concerning Watcom C and the confusion that can happen when handling 16:16 addresses in a 0:32 program. To me, the confusion could largely have been overcome by being a little more intelligent in the use of DosQueryProcAddr and first calling DosQueryProcType to see whether WinSetTitleAndIcon was 16- or 32-bit and calling the old, 16-bit version of Dos32QueryProcAddr instead. -- Regards, Mike Fry email: mikefry@iafrica.com   0 Mike 2/19/2004 4:54:58 PM Peter Moylan wrote: > > Paul Ratcliffe infrared: > >On 12 Feb 2004 05:28:00 GMT, Peter Moylan <peter@seagoon.newcastle.edu.au> > >wrote: > > > >> Is there any way a VIO application can set the text on the VIO > >> title bar? > > > >WinSetTitle or > >WinQuerySwitchHandle / WinQuerySwitchEntry / WinChangeSwitchEntry > > I've experimented with the second of these. It turns out that > WinChangeSwitchEntry does change the title in the window list > (the thing that comes up with Ctrl/Esc), but it doesn't change the > title bar of the VIO application. > > >> I have the various toolkit INF files, but it's not obvious which > >> one to search. I'm guessing that it needs to be a PM function, > >> but that only raises the question of how the VIO application can > >> find the right window handle. > > > >WinSetTitle doesn't need a handle. > > This sounds like a solution, but it might take me along a > time-consuming sidetrack. The software in question is written in > Modula-2, and I've never worked out in M2 how to thunk to a > 16-bit library function. Presumably I can track down documentation > that says how to do it in C, then visualize what that means > in assembly language and then translate that to M2, but to be > honest that sounds as if it will take more time than I want to > put into this job. > > My only reason for wanting to change the title bar was to put > some information there that was taking up valuable space in the > VIO window. If the job is too complex, I'm better off leaving > that information in the main window. > > -- > Peter Moylan Peter.Moylan@newcastle.edu.au > http://eepjm.newcastle.edu.au (OS/2 and eCS information and software) I would think that for a text-mode application you would use a text-mode type of call such as the Session Manager's (SESMGR.DLL) Ordinal #5, "DosSMSetTitle" (which is now forwarded into DOSCALLS.DLL #690). Since IBM left VIO as 16-bit, you might have to use this (or a similar) 16-bit API. Lars `  0 My 2/21/2004 3:41:32 PM  Reply: Similar Artilces: Timing Issue I have a quirky issue that I believe involves timing and only 2 hairs left to pull. I have a modal dialog that is an IFrame. The IFrame contains another window - which contains the appropriate title. I am trying to change the title of the IFrame window to be that of the contained window title. If I uncomment the alert statement below - the title change works. Comment out the alert - and - no title change. I have unsuccessfully tried using the following methods/events as timing devices: setTimeout, onload, onreadystatechange The problem appears to be that I have to make the title change b... Windows: setting title of console window I came across question http://stackoverflow.com/questions/6485678/ which has to do with setting the console title from sitecustomize.py. With some help from the folks on python-win32 (for the title portion ;) I came up with this: 8<-- sitecustomize.py --------------------------------- import sys import time from ctypes import windll class SetTitle(object): def __del__(self): time.sleep(.1) command = ' '.join(sys.argv) windll.kernel32.SetConsoleTitleA(command) sys.argv = SetTitle() 8<----------------------------------------------------- I ha... setting window title Is there any way to set my window title equal to my shell prompt "PS1" ? If the "PS1" changes the (as I change directories) the window title should also change. I have set my PS1 to indicate hostname, present working directory and the user name. Thanx for any help in advance... junky_fellow@yahoo.co.in writes: > Is there any way to set my window title equal to > my shell prompt "PS1" ? > If the "PS1" changes the (as I change directories) the > window title should also change. > I have set my PS1 to indicate hostname, present working di... How to set a pop-up new window rather than parent window highlig hted from ListCtrl on Mac OS Hi, I use Listctrl and from clicking a row on it a child window is poped up. On Mac OS, however, the child window is not highlighted ( newly created Childe window is on top of the parent window Listctrl on Win32 or Linux) i.e., parent window Listctrl is highlighted and is on top of newly created child window. How can I have a child window that is poped up from parent Listctrl be on top Of the parent window ? Many thanks ming --------------------------------------------------------------------- To unsubscribe, e-mail: wx-users-unsubscribe@lists.wxwidgets.org For addit... coloured text in VIO windows Hi, I used to know how produce coloured text and coloured backgrounds (ie not just the default white text on a black background). Can anyone point me to a description of how to this on OS/2? all the best, Jeremy Harbinson On 2005-11-26, Jeremy Harbinson <Jeremy.Harbinson@wur.nl> wrote: > Hi, > I used to know how produce coloured text and coloured backgrounds example: @echo off mode 80 33 set prompt=$e[0;47;30m$e[K$r[\$p] cls Franz Bakan wrote: > On 2005-11-26, Jeremy Harbinson <Jeremy.Harbinson@wur.nl> wrote: > >>Hi, >>I used to k...

Hi, [1] shows how to set the window title of the Editor: desktop = com.mathworks.mde.desk.MLDesktop.getInstance; jEditor = desktop.getGroupContainer('Editor').getTopLevelAncestor; jEditor.setTitle('This is the Matlab Editor'); I want to change the title of Simulink. I tried getGroupContainer('Simulink') etc. without luck. How can I do this? Thanks! [1] http://undocumentedmatlab.com/blog/accessing-the-matlab-editor ...

After I set the title with \title I cannot later expand the \@title macro?
My latex file is: ----------------- \documentclass{article}[12pt] \def\debug#1{\tracingmacros=2000 #1 \tracingmacros=0} \debug{\title{Current Stuff}} \begin{document} \debug{Title is {\@title}} \end{document} ---------------------- This produces an output file reading: "Title is title." For some reason, latex expands "\@" to a space or something, and then just writes out "title". I don't really understand what is going on here, and can't seem to search for things like "\@" on google. It was my understanding that "@" was not a spe...

Enabling a Unix OS in dual boot config with a Windows OS to maintain a valid keytab in Active Directory without invalidating the Windows OS's domain trust relationship
Dear List, This information is aimed at sites for which all of the following apply: - Sites that are using Active Directory as a Kerberos KDC - Sites that have dual-boot configured machines running both a Linux and W= indows based OS with the same hostname - Sites that want to have a working Kerberos keytab on the Linux OS, but w= ithout invalidating the trust relationship between the Windows OS and Activ= e Directory. This problem may be old news or may not apply, but it can be solved with a = few steps: Problem/Background: If a keytab is constructed for the Linux OS (using mskt= util, ...

Win32-API and setting window title
Hi All, how can I set the window title via a WIN32-API-function or is there another possibility ? Thanks On Thu, 15 Feb 2007 13:20:29 -0500, "Pit" <pharrendorf@am-soft.de> wrote: >Hi All, > >how can I set the window title via a WIN32-API-function or is there >another possibility ? > >Thanks Here is a discussion of getting Windows title bar text with win32-api, maybe you can use the same technique to set it? http://perlmonks.org?node_id=493609 But since this is a Tk newsgroup, dosn't the -title option work on windows? From ...

Set window title bar height?
I want to create those little yellow "hint" boxes that show up when the arrow floats over a button on a palette. Ordinarily I would do this by using a "plain" style window that I bring to the front. However, the palette window is a float window. Calling BringToFront on a plain window leaves it behind the floating windows, and thus, behind the palette. So I made the hint window a floating window too, and now BringToFront works fine, but it has a title bar. I made the title bar a side title bar and that makes it pretty innocuous frankly, but it would be bet...

OS/2 Vio* calls in Windows
Anyone familiar with OS/2 C Programming will remember all those handy Vio functions (VioWrtCharStr(), VioWrtNChar(), VioWrtNAttr(), VioGetCurPos(), VioSetCurPos(), etc...). Here's my question - does anyone know how I might be able to port a C program from OS/2 to windows that uses those calls extensively? I was thinking that _maybe_ since OS/2 and Windows started off "together" that the Vio API might somehow still be supported in Windows but I really haven't been able to turn up anything. Have any of you seen Vio calls made in windows through C? -----BEGIN PGP SIGNED MES...

how can set window title programmatically
how to set the window title programmatically for example the main vi i have a combo box&nbsp; which stores some names exp: abc &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; bcd &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cde then it will pass the data to another vi all the names use the same vi to display the data i want the window title to be the name of particular name user selected. &nbsp;can anyone help me? Hi jeyanthi, use a property node. connect the reference of the vi to it and select frontpanel-window -&gt; title. Mike ...

Setting the Command Prompt window title
When I use the Windows "title" command inside an ooRexx program it seems to have no effect. Is there a way around this? In the interim, I tried to get around this by renaming my test.rex to test.bat and inserting the following lines right at the top: /* @echo off title This is the taskeng.bat files doing rexx.exe E:\temp\taskeng.bat exit */ -- The remainder of the REXX code goes below this... This works, but of course the BAT processor objects to the "/*" command with: '/*' is not recognized as an internal or external com...

Setting custom KDE Window Titles?
Hi! Is it possible to change the window title (as appearing in the taskbar) for an arbitrary window? Especially after the window has started up? Anton __/ [ forum@anton.e4ward.com ] on Thursday 28 September 2006 11:17 \__ > Hi! > > Is it possible to change the window title (as appearing in the taskbar) > for an arbitrary window? Especially after the window has started up? > > Anton Hi, There are several programs which may permit this, e.g.: konsole -T 'SuSE Linux - Penguins become Reptiles' & Whether a KDE wrapper exists which applies this to virtually ...

Web resources about - Setting VIO window title text - comp.os.os2.programmer.misc

Help:Contents/Account settings and maintenance - Wikipedia, the free encyclopedia
Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc. , a non-profit organization.

Campaign setting - Wikipedia, the free encyclopedia
A campaign setting is usually a fictional world which serves as a setting for a role-playing game or wargame campaign. A campaign is a series ...

Privacy Setting For New Facebook Users Aged 13-17 Now Defaults To ‘Friends’
Facebook is changing the initial default privacy setting for users aged 13 through 17 to friends, from friends of friends, but those teen users ...

Facebook changes default privacy settings for new users to friends-only
Facebook announced today a shift in privacy settings for new users. Now, when someone signs up for a profile, their default posting status is ...

Bridie O'Donnell emotional after setting world hour record
An emotional Bridie O'Donnell rates cycling's world hour record as the best achievement of her life. She reached 46.882km, breaking the 46.273km ...

'Wonder Woman' movie: Chris Pine teases World War I setting with 500 extras
“Wonder Woman” movie will have “morally relevant themes,” Chris Pine teased in a recent interview.

In praise of boredom, setting us free from the trials of endless distraction
We live in a world petrified of boredom but maybe a little ennui is not such a bad thing.