Hi all,

I'm having problems with a program written in Delphi 1.0, running under
Windows 95. After using several windows in the program, a message follows:
'can not make window visual' or 'can not make visual window modal'. Is
this a known problem with Delphi 1.0 and Windows 95? Is there a solution
besides upgrading my Delphi to a higher version?  The program works fine
under Windows 3.11.

Please help, thanks a a lot,

-- Jan

----------------------------------------------------------------------------
Jan Hofman         |              >> This space left blank <<
jhof...@xs4all.nl  |              >>     intentionally     <<
----------------------------------------------------------------------------

I have not noticed anything like that with W95. And you can easily get the
same error message with W3.1 if you operate with the open modal forms
in wrong order. In W95 shows all the open D1 forms on Taskbar, if you don't
prevent this behaviour. An advanced W95 user usually uses task bar and
easily tries to re-open a 'wrong' Form.

With W3.11 this does not happen so easily, because the topmost form hides
the one in the background, and user has first to close the foreground form
before trying to do some operation on the background form.

If that was the reason, put this code in to your .DPR project file. It
prevents several D1 forms being visible on W95 taskbar:

Var
  wStyle: LongInt;
begin
   { Set the application window style, to only have the Application
    Window in the Win95 Taskbar. }
  wStyle := getWindowLong(Application.Handle, GWL_Style);
  wStyle := wStyle or ws_Caption;
  setWindowLong(Application.Handle, GWL_Style, wStyle);

Markku Nevalainen

  #1:  Upgrade anyway...  It's stupid to program 16bit in a 32bit
enviroment....  (my two cents...)

  #2:  No, no problems...  It's going to be in your code...   I'd make sure
the window's visible is set to true, and make sure you're not setting it to
invisible anywhare....  ---  Secondly, you can't show a window, and then
turn it to modal without first closing it...  Again, your code...

--
Jason Wallace
SL Software
Dark...@SLSoftware.reno.nv.us
--
"We are Microsoft.  Resistance is Futile.  You will be Assimiliated."

-

Hmm.... it may be not that stupid if you want to be able to run the same
exe under both 3.11 and 95...

As I said... the program works fine under 3.11...

  And when the 16bit kernel goes away, and 16bit app's no longer work under
the newer versions of Windows?  --  Something to think about....

 I'd still double check the code....  --  There's little to no difference
between Win95 and Win3.x (both have the 16bit kernel (the reason for
backwards compatability) so if it works in one, it'll work in the
ther...)  --  Something in Win95 may be arguing with something that Win3.x
didn't care about...  (an API call, memory allocation, stacks...  Heck,
almost anything....)  ---  If you have the professional version or better,
I'd take a look at WinSight and see what it says your app. is doing...

Jason Wallace
SL Software
Dark...@SLSoftware.reno.nv.us
--
"We are Microsoft.  Resistance is Futile.  You will be Assimiliated."

I really don't know what is there to think about? Everybody knows that the newest
available (coming) Windows -version is the W98, and the old 16-bit apps run
fine there.

I suppose everybody who writes apps that must be run both under 16 and 32 bit
systems knows that 16-bit is not going to be here for ever. Also their clients
know it. But I also don't understand the intelligence when somone repeatedly
"answers" posting 'hey, upgrade to 32-bit', when someone asks anything about
code that _must_ run both under 16 and 32 bit _now_.

I think that full obvious, clever, upgrade hint has now been heard. But I really
doubt if it has ever been anything new to anyone, or if it has been for any help
for anybody.

Markku Nevalainen

In article <01bd7bf5$54229b40$1c326dc2@default>, Jan Hofman
<jhof...@xs4all.nl> writes

FWIW, I agree. We have many customers still running 3.1x and we have
better things to do than support 2 lots of exe's for all the
applications we have.

Regards,

Mike

--
Mike

NB - All opinions are my own, not necessarily that of my employer.