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. Post Follow

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).

What's your point?

-- 
 -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...

Setting Simulink window title
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.

Turkey setting ‘poor example’ for freedom of expression: Biden
Turkey setting ‘poor example’ for freedom of expression: Biden

Schadenfreude Open Thread: Jeb Now Setting Fire to Big Stacks of Cash
Jeb! Super PAC mailing out New Hampshire voters mini DVD players with charging cable and documentary. pic.twitter.com/Qez5B5ZRxD — sean (@SeanMcElwee) ...

Smartphone shipments reach 1.43 billion units, setting new record
IDC has released its report on smartphone shipments in 2015, revealing record numbers for both Q4 and the whole year. In the last three months ...

Resources last updated: 1/31/2016 3:20:44 PM