Dear Alaska Support Team,

There are several problems with the new XbpPack2 demo test program and 
the new XbpProgressBar() class.

If no manifest is used, all progress bars show the segmented-type 
progress bar (as expected), but the display isn't refreshed after the 
progress bar reaches its maximum value. The only way to force a refresh 
in that case is to minimize the dialog or move it out of the desktop area. 

And if this is done, the background of the progress bar will apparently 
become transparent for a moment, and then will show whatever was behind 
the progress bar dialog at the time of the refresh, until the dialog is
refreshed again. This means that the XbpProgressBar() class isn't usable 
without a manifest file.

In addition, the "Test.prg" has in line 129 of the Main() Procedure the 
following line of code:

SetAppWindow():Destroy()

This line will cause an IDSC. On my Windows XP computer this isn't quite
obvious, as the program terminates anyway at that point. But on my 
Windows 7 computer, this line results in an XppFatal.log error, as the
standard "StandardEH()" function in the default "ErrorSys.prg" that is
included in the "XbpSys.dll" file will run into a follow-on error in
line 202, where the "ConfirmBox()" function is called. As that particular
call to ConfirmBox() omits the first parameter, the oOwner value, it will 
default to SetAppWindow(). If you include a replacement ErrorSys.prg file 
and change the ConfirmBox() call to use "AppDesktop()" as oOwner, then 
the IDSC is shown and a normal "XppError.log" file is created.

The easiest way to fix this, is to replace line 129 of the "Test.prg"
file with either this:

oDlg:Destroy()

or to completely remove this unnecessary line altogether. I don't think 
that a line like "SetAppWindow():Destroy()" should ever be used at all -- 
especially not in demo programs by Alaska -- and using it shouldn't result 
in an IDSC, either.

I have attached the above mentioned XppFatal.log and XppError.log files.
If don't think that screen shots of the incorrectly working Progress bars
are necessary, as this can easily be reproduced by simply renaming (or
deleting) the "test.exe.manifest" file before running the existing test 
program.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Sorry, I forgot to attach the error logs. Here they are.

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Hi Andreas,

(...)
> SetAppWindow():Destroy()
>
> This line will cause an IDSC.
(...)

Unfortunately, you're right; SetAppWindow() references the desktop object at
this point (AppDesktop()) - a bad thing to destroy really. All code using
this (now invalid) object afterwards will fail. The call to ConfirmBox() made by
the error handler is a case in point.

I agree with you on both accounts:

1. AppDesktop():Destroy() should not have such devastating effects. This will be
    corrected.
2. The code line in itself is dead wrong. I'm assuming it is a left over from a
     time where SetAppWindow() did point to the form object - meant to
     test XbpProgressBar:Destroy() perhaps?

> If no manifest is used, all progress bars show the segmented-type
> progress bar (as expected), but the display isn't refreshed after the
> progress bar reaches its maximum value.

It seems the "classic" progress bar does not erase its background in certain
places. This is what you meant, isn't it? How strange...

Thanks for pointing this out. I'll look into it!

Best regards,
  Till Warweg
  [Alaska Software]

--------------------------------------------------------------------
Technical Support:         support@alaska-software.com
News Server:                 news.alaska-software.com
Homepage:                     http://www.alaska-software.com
KnowledgeBase:            http://www.alaska-software.com/kb
--------------------------------------------------------------------



"Andreas Gehrs-Pahl" schrieb im Newsbeitrag 
news:qjtifcvh77tu$.zdoykxrhiidq$.dlg@40tude.net...
> Dear Alaska Support Team,
>
> There are several problems with the new XbpPack2 demo test program and
> the new XbpProgressBar() class.
>
> If no manifest is used, all progress bars show the segmented-type
> progress bar (as expected), but the display isn't refreshed after the
> progress bar reaches its maximum value. The only way to force a refresh
> in that case is to minimize the dialog or move it out of the desktop area.
>
> And if this is done, the background of the progress bar will apparently
> become transparent for a moment, and then will show whatever was behind
> the progress bar dialog at the time of the refresh, until the dialog is
> refreshed again. This means that the XbpProgressBar() class isn't usable
> without a manifest file.
>
> In addition, the "Test.prg" has in line 129 of the Main() Procedure the
> following line of code:
>
> SetAppWindow():Destroy()
>
> This line will cause an IDSC. On my Windows XP computer this isn't quite
> obvious, as the program terminates anyway at that point. But on my
> Windows 7 computer, this line results in an XppFatal.log error, as the
> standard "StandardEH()" function in the default "ErrorSys.prg" that is
> included in the "XbpSys.dll" file will run into a follow-on error in
> line 202, where the "ConfirmBox()" function is called. As that particular
> call to ConfirmBox() omits the first parameter, the oOwner value, it will
> default to SetAppWindow(). If you include a replacement ErrorSys.prg file
> and change the ConfirmBox() call to use "AppDesktop()" as oOwner, then
> the IDSC is shown and a normal "XppError.log" file is created.
>
> The easiest way to fix this, is to replace line 129 of the "Test.prg"
> file with either this:
>
> oDlg:Destroy()
>
> or to completely remove this unnecessary line altogether. I don't think
> that a line like "SetAppWindow():Destroy()" should ever be used at all -- 
> especially not in demo programs by Alaska -- and using it shouldn't result
> in an IDSC, either.
>
> I have attached the above mentioned XppFatal.log and XppError.log files.
> If don't think that screen shots of the incorrectly working Progress bars
> are necessary, as this can easily be reproduced by simply renaming (or
> deleting) the "test.exe.manifest" file before running the existing test
> program.
>
> -- Andreas
>
> ---                                                                      ---
>  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>  415 Gute Street                     or: Andreas@DDPSoftware.com
>  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
>  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---

Till,

Sorry, but I have a couple of nits to pick. 

>Unfortunately, you're right; SetAppWindow() references the desktop object at
>this point (AppDesktop()) - a bad thing to destroy really. All code using
>this (now invalid) object afterwards will fail. The call to ConfirmBox() made 
>by the error handler is a case in point.

SetAppWindow() references AppDesktop() at every point in that program, as
SetAppWindow() isn't assigned anywhere in the code, but keeps its default
value -- which apparently is AppDesktop() -- because the AppSys() procedure 
was overloaded with an empty routine.

Actually, if you explicitly use "AppDesktop()" in the call to ConfirmBox() 
as oOwner, no error is raised in the ConfirmBox() line, and the original
IDSC error from the call to :Destroy() is displayed without a problem. That
means that you can actually use and reference AppDesktop() just fine after 
the :Destroy() method was called. The error occurs because the :Destroy()
method is called -- not because the AppDesktop() object was destroyed -- 
as it really isn't. You can check AppDesktop():Status() after calling 
AppDesktop():Destroy(), and it will return XBP_STAT_CREATE (1). This also
means that AppDesktop() isn't (returning) an "invalid object" at any time,
even after the :Destroy() method was called!

I think adding: "SetAppWindow(oDlg)" somewhere after line 52 would fix the
problem, too, as AppDesktop() wouldn't be the same as SetAppWindow(), and
the program logic would make more sense. The "oDlg" dialog isn't destroyed
anywhere in the code and will simply exist until the program terminates.
It will still be shown -- and all the Threads will still be running and the 
four progress bars will continue to be updated -- even while and after the 
error ConfirmBox() is displayed. 

>It seems the "classic" progress bar does not erase its background in certain
>places. This is what you meant, isn't it? How strange...

As long as the manifest file exists, using "oProgress:UseVisualStyle := .f."
will create a working "classic" progress bar, so it is only a problem if
there is no manifest file. And yes, without a manifest file, all progress
bars are forced to be "classic", and don't erase their background anymore.
In addition, they "capture" the underlying background -- from behind the
parent dialog -- when they are refreshed (via restore). 

Anyway, will there be a couple of PDRs created for those two issues?

1) AppDesktop():Destroy() causes IDSC.
2) XbpProgressBar() doesn't paint its background if .not. IsThemeActive().

Thanks,

-- Andreas

---                                                                      ---
  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
  415 Gute Street                     or: Andreas@DDPSoftware.com
  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
---                                                                      ---

Hi Andreas,

Well, I think your assumption ...

> (...) That means that you can actually use and reference AppDesktop() just
> fine after the :Destroy() method was called.

... is a bit strong considering that it is based on a test being run while the
system was trying to tell you just the opposite (i.e. within the error handler
triggered in :Destroy()) !

Just kidding .

What happens internally is that as part of the destroy sequence of the
desktop object, the object referenced by SetAppWindow() is reset to
something illegal. It is at this point that your error handler is called,
possibly operating on stale data (see the value AppDesktop():Status()).
So even if you manage to get away calling ConfirmBox(), some thing
will break sooner or later. If not now, then in a future version.

> As long as the manifest file exists, using "oProgress:UseVisualStyle := .f."
> will create a working "classic" progress bar, so it is only a problem if
> there is no manifest file. And yes, without a manifest file, all progress
> bars are forced to be "classic", and don't erase their background anymore.

Okay. This is valuable info! I hadn't tried changing :UseVisualStyle yet,
assuming the behaviour would be the same. Funny how things changed
between the versions of the common controls DLL, huh? It seems
"Classic" mode exists in several revisions .

> Anyway, will there be a couple of PDRs created for those two issues?
> 1) AppDesktop():Destroy() causes IDSC.
> 2) XbpProgressBar() doesn't paint its background if .not. IsThemeActive().

Oh yes. I'll do that as soon as I've recovered from this exchange. You're
keeping me on my toes writing so fast .

Best regards,
  Till Warweg
  [Alaska Software]

--------------------------------------------------------------------
Technical Support:         support@alaska-software.com
News Server:                 news.alaska-software.com
Homepage:                     http://www.alaska-software.com
KnowledgeBase:            http://www.alaska-software.com/kb
--------------------------------------------------------------------



"Andreas Gehrs-Pahl" schrieb im Newsbeitrag 
news:gfzc79q2b1h8.1diyxamqds1w1$.dlg@40tude.net...
> Till,
>
> Sorry, but I have a couple of nits to pick. ;-)
>
>>Unfortunately, you're right; SetAppWindow() references the desktop object at
>>this point (AppDesktop()) - a bad thing to destroy really. All code using
>>this (now invalid) object afterwards will fail. The call to ConfirmBox() made
>>by the error handler is a case in point.
>
> SetAppWindow() references AppDesktop() at every point in that program, as
> SetAppWindow() isn't assigned anywhere in the code, but keeps its default
> value -- which apparently is AppDesktop() -- because the AppSys() procedure
> was overloaded with an empty routine.
>
> Actually, if you explicitly use "AppDesktop()" in the call to ConfirmBox()
> as oOwner, no error is raised in the ConfirmBox() line, and the original
> IDSC error from the call to :Destroy() is displayed without a problem. That
> means that you can actually use and reference AppDesktop() just fine after
> the :Destroy() method was called. The error occurs because the :Destroy()
> method is called -- not because the AppDesktop() object was destroyed -- 
> as it really isn't. You can check AppDesktop():Status() after calling
> AppDesktop():Destroy(), and it will return XBP_STAT_CREATE (1). This also
> means that AppDesktop() isn't (returning) an "invalid object" at any time,
> even after the :Destroy() method was called!
>
> I think adding: "SetAppWindow(oDlg)" somewhere after line 52 would fix the
> problem, too, as AppDesktop() wouldn't be the same as SetAppWindow(), and
> the program logic would make more sense. The "oDlg" dialog isn't destroyed
> anywhere in the code and will simply exist until the program terminates.
> It will still be shown -- and all the Threads will still be running and the
> four progress bars will continue to be updated -- even while and after the
> error ConfirmBox() is displayed.
>
>>It seems the "classic" progress bar does not erase its background in certain
>>places. This is what you meant, isn't it? How strange...
>
> As long as the manifest file exists, using "oProgress:UseVisualStyle := .f."
> will create a _working_ "classic" progress bar, so it is only a problem if
> there is no manifest file. And yes, without a manifest file, all progress
> bars are forced to be "classic", and don't erase their background anymore.
> In addition, they "capture" the underlying background -- from behind the
> parent dialog -- when they are refreshed (via restore).
>
> Anyway, will there be a couple of PDRs created for those two issues?
>
> 1) AppDesktop():Destroy() causes IDSC.
> 2) XbpProgressBar() doesn't paint its background if .not. IsThemeActive().
>
> Thanks,
>
> -- Andreas
>
> ---                                                                      ---
>  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>  415 Gute Street                     or: Andreas@DDPSoftware.com
>  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
>  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
> ---                                                                      ---

Andreas et all,

  FYI: the PDRs on the AppDesktop():Destroy() and progress bar-doesn't
erase issues have gone public. I've included the links for your reference.

http://www.alaska-software.com/scripts/waa001.dll?WAA_PACKAGE=PUBLICDTS&WAA_FORM=DISPLAYPDR&PDRID=6306
http://www.alaska-software.com/scripts/waa001.dll?WAA_PACKAGE=PUBLICDTS&WAA_FORM=DISPLAYPDR&PDRID=6307

A viable (though a bit crude) work-around for the latter problem is to 
hide and re-show the progress bar whenever a new value to be set
is lower than the current one. 

If nothing else develops, I'll have the package on our servers updated 
next week. And yes, the update will also get rid of the offending line

  SetAppWindow():Destroy()

.

Good one, thank you!

Regards,
  Till Warweg
  [Alaska Software]

--------------------------------------------------------------------
Technical Support:         support@alaska-software.com
News Server:                 news.alaska-software.com
Homepage:                     http://www.alaska-software.com
KnowledgeBase:            http://www.alaska-software.com/kb
--------------------------------------------------------------------



"Till Warweg" schrieb im Newsbeitrag news:3c6343d8$37cece98$29dc7@news.alaska-software.com...
> Hi Andreas,
> 
> Well, I think your assumption ...
> 
>> (...) That means that you can actually use and reference AppDesktop() just
>> fine after the :Destroy() method was called.
> 
> ... is a bit strong considering that it is based on a test being run while the
> system was trying to tell you just the opposite (i.e. within the error handler
> triggered in :Destroy()) !
> 
> Just kidding ;-).
> 
> What happens internally is that as part of the destroy sequence of the
> desktop object, the object referenced by SetAppWindow() is reset to
> something illegal. It is at this point that your error handler is called,
> possibly operating on stale data (see the value AppDesktop():Status()).
> So even if you manage to get away calling ConfirmBox(), some thing
> will break sooner or later. If not now, then in a future version.
> 
>> As long as the manifest file exists, using "oProgress:UseVisualStyle := .f."
>> will create a _working_ "classic" progress bar, so it is only a problem if
>> there is no manifest file. And yes, without a manifest file, all progress
>> bars are forced to be "classic", and don't erase their background anymore.
> 
> Okay. This is valuable info! I hadn't tried changing :UseVisualStyle yet,
> assuming the behaviour would be the same. Funny how things changed
> between the versions of the common controls DLL, huh? It seems
> "Classic" mode exists in several revisions ;-).
> 
>> Anyway, will there be a couple of PDRs created for those two issues?
>> 1) AppDesktop():Destroy() causes IDSC.
>> 2) XbpProgressBar() doesn't paint its background if .not. IsThemeActive().
> 
> Oh yes. I'll do that as soon as I've recovered from this exchange. You're
> keeping me on my toes writing so fast ;-).
> 
> -- 
> Best regards,
>  Till Warweg
>  [Alaska Software]
> 
> --------------------------------------------------------------------
> Technical Support:         support@alaska-software.com
> News Server:                 news.alaska-software.com
> Homepage:                     http://www.alaska-software.com
> KnowledgeBase:            http://www.alaska-software.com/kb
> --------------------------------------------------------------------
> 
> 
> 
> "Andreas Gehrs-Pahl" schrieb im Newsbeitrag 
> news:gfzc79q2b1h8.1diyxamqds1w1$.dlg@40tude.net...
>> Till,
>>
>> Sorry, but I have a couple of nits to pick. ;-)
>>
>>>Unfortunately, you're right; SetAppWindow() references the desktop object at
>>>this point (AppDesktop()) - a bad thing to destroy really. All code using
>>>this (now invalid) object afterwards will fail. The call to ConfirmBox() made
>>>by the error handler is a case in point.
>>
>> SetAppWindow() references AppDesktop() at every point in that program, as
>> SetAppWindow() isn't assigned anywhere in the code, but keeps its default
>> value -- which apparently is AppDesktop() -- because the AppSys() procedure
>> was overloaded with an empty routine.
>>
>> Actually, if you explicitly use "AppDesktop()" in the call to ConfirmBox()
>> as oOwner, no error is raised in the ConfirmBox() line, and the original
>> IDSC error from the call to :Destroy() is displayed without a problem. That
>> means that you can actually use and reference AppDesktop() just fine after
>> the :Destroy() method was called. The error occurs because the :Destroy()
>> method is called -- not because the AppDesktop() object was destroyed -- 
>> as it really isn't. You can check AppDesktop():Status() after calling
>> AppDesktop():Destroy(), and it will return XBP_STAT_CREATE (1). This also
>> means that AppDesktop() isn't (returning) an "invalid object" at any time,
>> even after the :Destroy() method was called!
>>
>> I think adding: "SetAppWindow(oDlg)" somewhere after line 52 would fix the
>> problem, too, as AppDesktop() wouldn't be the same as SetAppWindow(), and
>> the program logic would make more sense. The "oDlg" dialog isn't destroyed
>> anywhere in the code and will simply exist until the program terminates.
>> It will still be shown -- and all the Threads will still be running and the
>> four progress bars will continue to be updated -- even while and after the
>> error ConfirmBox() is displayed.
>>
>>>It seems the "classic" progress bar does not erase its background in certain
>>>places. This is what you meant, isn't it? How strange...
>>
>> As long as the manifest file exists, using "oProgress:UseVisualStyle := .f."
>> will create a _working_ "classic" progress bar, so it is only a problem if
>> there is no manifest file. And yes, without a manifest file, all progress
>> bars are forced to be "classic", and don't erase their background anymore.
>> In addition, they "capture" the underlying background -- from behind the
>> parent dialog -- when they are refreshed (via restore).
>>
>> Anyway, will there be a couple of PDRs created for those two issues?
>>
>> 1) AppDesktop():Destroy() causes IDSC.
>> 2) XbpProgressBar() doesn't paint its background if .not. IsThemeActive().
>>
>> Thanks,
>>
>> -- Andreas
>>
>> ---                                                                      ---
>>  Andreas Gehrs-Pahl              E-Mail: GPahl@CharterMI.net
>>  415 Gute Street                     or: Andreas@DDPSoftware.com
>>  Owosso, MI 48867-4410               or: Andreas_Gehrs-Pahl@CrimeCog.com
>>  Tel: (989) 723-9927           Web Site: http://www.Aerospace-History.net
>> ---                                                                      ---  
>