🚀 go-pugleaf

Juan Diego Garc�s wrote:
> When I use the BringToFront method of the TApplication Class, the only thing
> can I see, is the icon of the application that is blinking in the taskbar,
> but the application in not brought to the front.

The behaviour has changed with Win98/WinXP.
Only threads with attached input queues can
force another processes' window to pop up.

You will find some code that uses AttachInput
and/or SetWindowPos in the related newgroups.

For additional information look at MSDN docs.

Juan Diego Garc�s wrote:
> When I use the BringToFront method of the TApplication Class, the only thing
> can I see, is the icon of the application that is blinking in the taskbar,
> but the application in not brought to the front.
> 
> This method in Win NT works fine. What have I do to get the same behaivor of
> this method in Win 2000/XP?
> 
> Thanks
> 
> Juan Diego Garc�s
> 
> 

I think you'll find that it doesn't work on Window 98/Me, either. The 
operating system was deliberately changed to prevent any process from 
forcing itself into the foreground, presumably for reasons of security. 
There is a way to get the old behavior, but it requires modifying the 
system registry. The Microsoft platform SDK docs entry for 
SetForegroundWindow() has the details.

,

> I think you'll find that it doesn't work on Window 98/Me, either. The 
> operating system was deliberately changed to prevent any process from 
> forcing itself into the foreground, presumably for reasons of security.
>

It's also a user friendly option. I never liked programs forcing 
themselves to the foreground (Builder is one culprit that used to drive 
me mad, another was Lotus Notes).

Flashing their icon a few times is enough IMO. It lets me know they want 
attention but lets me get round to servicing them in my own time.

Please Juan, unless you're writing software to monitor nuclear 
powerstation cores ask yourself if your users really will want to be 
interrupted by your application demanding attention. Most of the time IMO 
it's just rude.

Andrue Cope
[Bicester, UK]

I write real time applications to control stations for water treatment, an
sometimes when there is an alarm I have to show a big window, the I have to
use this function.

Thanks

Juan Diego Garc�s,

> I write real time applications to control stations for water treatment, an
> sometimes when there is an alarm I have to show a big window, the I have to
> use this function.
>

Yah - that's a good excuse :)

Andrue Cope
[Bicester, UK]

> I write real time applications to control stations for water
treatment, an
> sometimes when there is an alarm I have to show a big window, the I
have to
> use this function.

Well, in that case... maybe the information here:
http://www.hp-eloquence.com/sdb/html/1030696073.html
will be of use?

"Juan Diego Garc�s" <jgarces@amics.ch> wrote in message
news:3ebb8936@newsgroups.borland.com...
> When I use the BringToFront method of the
> TApplication Class, the only thing can I see, is
> the icon of the application that is blinking in the
> taskbar, but the application in not brought
> to the front.

If the application was not already the input-active process (the process
receiving the user's input) when you call BringToFront(), then the
application cannot bring itself it to the front.  The OS won't allow it.
Only the input-active process is allowed to set the foreground window.
TApplication::BringToFront() uses the SetForegroundWindow() function, but
Microsoft made a behavioral change to SetForegroundWindow() in Win98 and
Win2K to prevent exactly what you are trying to do.

> This method in Win NT works fine. What have
> I do to get the same behaivor of this method
> in Win 2000/XP?

Have a look at Microsoft's documentation for SetForegroundWindow() for
information about the issue:

    SetForegroundWindow Function
    http://makeashorterlink.com/?T22E16184


Gambit

Juan Diego Garc�s <jgarces@amics.ch> wrote in message
news:3ebbbe97@newsgroups.borland.com...
> I write real time applications to control stations for water
treatment, an
> sometimes when there is an alarm I have to show a big window, the I
have to
> use this function.

Juan, I realize that you don't set the policies of your department or
your company.  But do *they* know that the EULA for all versions of
Windows I know *say* that Windows is not intended for real-time or
process-control applications?  They are assuming some element of risk,
despite the worldwide hegemony of Windows!

--
Timothy H. Buchman
========================================
City Center Theater, New York NY
mail address tbuchmanPLEASE(at sign)REMOVEcitycenter.org
Search .borland message archive on http://www.mers.com/searchsite.html

I have to respond you that if you want to use a good SCADA application you have to use Windows. For exemple: Wonderware, the Rockwell SCADA, Factory Link, Monitor, only work in Windows.

I work in Schneider Electric, we produce the PLCs
telemecanique, Modicon, etc... and we use only Windows to make
our real time systems, we use also OPC (OLE for process
control) that is linked directly to Windows. All the protocols
to communicate with the PLCs (for exemple, Ethway, XIP,
Unitelway, Fipway, etc..) were writed (in their last versions,
before we used OS/2) to work only with Windows.

We don't have problems with Windows, there are many
applications that we have made that runs many time (months)
until we have to stopped it to make a defrag, or a back up.
If you think that you can't make a good real time application
in Windows you are wrong. you have to use Win NT, 2000 or XP.
Win 95, 98 and ME are not good.

Juan Diego Garc�s


>Juan, I realize that you don't set the policies of your department or
>your company.  But do *they* know that the EULA for all versions of
>Windows I know *say* that Windows is not intended for real-time or
>process-control applications?  They are assuming some element of risk,
>despite the worldwide hegemony of Windows!
>
>--
>Timothy H. Buchman
>========================================
>City Center Theater, New York NY
>mail address tbuchmanPLEASE(at sign)REMOVEcitycenter.org
>Search .borland message archive on http://www.mers.com/searchsite.html
>

Is not an excuse, Our application is really a set of 5 programs that have to work together: There is an applic. that makes the communication with the PLCs, another one that shows the synoptique images to control the station, another one that is the boss of others...

Then, when the user want to send a command to the PLC, he has to click the object that he wants (in the synoptique applic.) and the boss application has to show a window where the user can set the new value. Then this new window has to be brought in front. This is a short and quick explanation of what we make.

Thanks.


>
>Yah - that's a good excuse :)
>
>Andrue Cope
>[Bicester, UK]
>

Juan Diego Garc�s,

> We don't have problems with Windows, there are many
> applications that we have made that runs many time (months)
> until we have to stopped it to make a defrag, or a back up.
> If you think that you can't make a good real time application
> in Windows you are wrong.
>

He's not saying that. What he's saying is that the company that 
designed, implemented and supports the OS (the World's biggest 
software company) publicly states that it is not intended to be a 
real-time OS.

This means that your company is using this OS in a way not intended 
or guaranteed by the manufacturer. Should something go wrong this 
would I imagine make your company entirely liable for the 
consequences.

Andrue Cope
[Bicester, UK]