hi,

with Codejock SkinFramework we found out a Problem with ISTHEMEACTIVE(1130)
as you can read it in SL1 Forum you can fix it yourself, but what about v331 
?

SL1 does have a XPPSYS.DLL which are made from
C:\Alaska\XPPW32\source\SYS\
C:\Alaska\XPPW32\source\COMPAT\
as you can read it in C:\ALASKA\XPPW32\SOURCE\DLL\PROJECT.XPJ for SL1

i think v331 User "NEED" that Project File too to build a XPPSYS.DLL for 
v331

greetings by OHR
Jimmy

Jimmy,

>with Codejock SkinFramework we found out a Problem with ISTHEMEACTIVE(1130)
>as you can read it in SL1 Forum you can fix it yourself, but what about 
>v331?

Pretty much the same.

>i think v331 User "NEED" that Project File too to build a XPPSYS.DLL for 
>v331

As there is no "XppSys.dll" in Xbase++ Version 1.90.331, there is no need
for such a project file. Simply copy this function into your own source
code and fix it there, or include the (modified/corrected) "XbpParts.prg"
file in your project. In either case, your own "IsThemeActive()" function 
is used instead of the default one. As the OOP-model in 1.90.331 is quite
different from the one in SL-1, there shouldn't be any problem with the
Xbase++ base-classes also using your corrected code instead of the 
original function, which is located in the "XppRT1.dll" (in 1.90.331).

The "XppSys.dll" file was only introduced in SL-1, to separate all those 
routines out of the base runtime files, so it is easier to replace those
classes and other routines. If you create your own copy/version of such 
functions in your own code, they will still "replace" the default ones,
even in SL-1. 

Anyway, if and when SL-1 is released (and working), there shouldn't be 
any need to use 1.90.331, anymore. And SL-1 IS the fix for 1.90.331!

-- Andreas

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

hi,

> Anyway, if and when SL-1 is released (and working), there shouldn't be
> any need to use 1.90.331, anymore. And SL-1 IS the fix for 1.90.331!

but SL1 include "visual Style" so the "look & feeling" of your Application
will change. you have to rewrite your v331 Source as i did it last 11 Month
to "bet back" old Style or enhance it with new SL1 Futures.

depending on what you need, SL1 is not a "must have".  SL1 does not
include many new Futures "ready to use" like enhance Ownerdrawing.

like "visuelle Style" you have to modify "working" Source which meen
a lot of work. If Alaska would have use :useVisualStyle := .F. as default
all woud be fine -> same "look & feeling" -> no work..

but if use :useVisualStyle := .F., why should i use SL1 ?

only XbpToolbar BUG is not as Hotfix avaiable for v331, but it is
a activeX and we have the Source.

i only need XbpIcon from SL1 for v331, but v331 does not have
"XbpBaseImage", so i do not know how to create my own Icon Class ?

greetings by OHR
Jimmy

Hi,

The upcoming Service Level1 for Xbase++ 1.90 is clearly focused on
Windows Vista support. For this, a huge area of the underlaying
Xbase++ GUI engine was reworked. Furthermore a lot of new features
and functions have been introduced.

It was important for us to enable you to adapt your existing application
to the enhanced visual appearance of the latest Windows platforms.
Furthermore, we had to decide about the default appearance when
new application are to be created. To us it was no question that
this must be the default appearance of the windows platform - a belief
other community members agreed to.

At the same point of time we have been aware of the fact that
a lot of XbaseParts have been customized in beautiful applications.
It is our responsibility that existing code will not be broken
with new Xbase++ releases - at least we need to give a clear
statement if this is the case.

So how to resolve this conflict?

In case of the visual styles we decided to introduce an application
wide switch so you are able to achieve the accustomed behaviour. The new
class XbpApplication has an access assign IVar that gives you quite
fine control about the applications behaviour. Adding two lines of
code is an effort we think you can do when switching from one version
to another.

=========================== snip =================================
    #include "applictn.ch"
    /* provides
    XBPAPP_NOSTYLES      Disable visual styles for the application
    XBPAPP_DIALOGSTYLES  Enable visual styles for forms and dialogs
    XBPAPP_CHILDSTYLES   Enable visual styles for Xbase Parts created
                         as childs of a form object
    XBPAPP_ALLSTYLES     Enable visual styles for all user interface
                         elements
    */


    ...

    XbpApplication():enableVisualStyles := XBPAPP_DIALOGSTYLES
=========================== snap =================================

This and the IVar :useVisualStyle introduced on the XbpWindow class
(and thus on all derived classes) will give all control and flexibility
for any case - existing applications and new applications.

 > depending on what you need, SL1 is not a "must have".

If you need to have your development tool up to date, SL1 is a must
have. If you like to benefit from more then 140 closed PDRs and more
then 170 new features and enhancements, SL1 is a must have. If you like
to be preparred for the upcoming Artica technology and future releases
of the VX system, SL1 is a must have. If you like to be preparred
for new technologies and future Windows platforms, SL1 is a must have.
Not going the SL1 road could be at least a little bit dangerous.

With my best regards,

   Andreas Herdt
   Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

AUGE_OHR wrote:
> hi,
> 
>> Anyway, if and when SL-1 is released (and working), there shouldn't be
>> any need to use 1.90.331, anymore. And SL-1 _IS_ the fix for 1.90.331!
> 
> but SL1 include "visual Style" so the "look & feeling" of your Application
> will change. you have to rewrite your v331 Source as i did it last 11 Month
> to "bet back" old Style or enhance it with new SL1 Futures.
> 
> depending on what you need, SL1 is not a "must have".  SL1 does not
> include many new Futures "ready to use" like enhance Ownerdrawing.
> 
> like "visuelle Style" you have to modify "working" Source which meen
> a lot of work. If Alaska would have use :useVisualStyle := .F. as default
> all woud be fine -> same "look & feeling" -> no work..
> 
> but if use :useVisualStyle := .F., why should i use SL1 ?
> 
> only XbpToolbar BUG is not as Hotfix avaiable for v331, but it is
> a activeX and we have the Source.
> 
> i only need XbpIcon from SL1 for v331, but v331 does not have
> "XbpBaseImage", so i do not know how to create my own Icon Class ?
> 
> greetings by OHR
> Jimmy
> 
> 
>

Andreas,

thank you for pointing that out. Just let me say some words about that.

I can understand that some developers are concerned about: What will 
happen to all my optical stuff in my apps if I change to SL1? I found my 
own way to handle that, but I only need that to change that for my 
browses. Other developers may need to do some more work.

Sometimes I can not understand the discussion about themes in SL1. A lot 
of people asked very resolute for supporting themes in XP and Vista. Now 
we do have this, and again it is wrong.

But: I also think that a lot of stress and bad feeling could have been 
avoided if Alaska would have written some more about how to handle it a 
bit earlier. A lot of the stuff Alaska is doing is good, we have waited 
for it, we really need it. But it is not communicated to the developers. 
The old problem.

Just my thoughts about that.

Jan


Andreas Herdt schrieb:
> Hi,
> 
> The upcoming Service Level1 for Xbase++ 1.90 is clearly focused on
> Windows Vista support. For this, a huge area of the underlaying
> Xbase++ GUI engine was reworked. Furthermore a lot of new features
> and functions have been introduced.
> 
> It was important for us to enable you to adapt your existing application
> to the enhanced visual appearance of the latest Windows platforms.
> Furthermore, we had to decide about the default appearance when
> new application are to be created. To us it was no question that
> this must be the default appearance of the windows platform - a belief
> other community members agreed to.
> 
> At the same point of time we have been aware of the fact that
> a lot of XbaseParts have been customized in beautiful applications.
> It is our responsibility that existing code will not be broken
> with new Xbase++ releases - at least we need to give a clear
> statement if this is the case.
> 
> So how to resolve this conflict?
> 
> In case of the visual styles we decided to introduce an application
> wide switch so you are able to achieve the accustomed behaviour. The new
> class XbpApplication has an access assign IVar that gives you quite
> fine control about the applications behaviour. Adding two lines of
> code is an effort we think you can do when switching from one version
> to another.
> 
> =========================== snip =================================
>    #include "applictn.ch"
>    /* provides
>    XBPAPP_NOSTYLES      Disable visual styles for the application
>    XBPAPP_DIALOGSTYLES  Enable visual styles for forms and dialogs
>    XBPAPP_CHILDSTYLES   Enable visual styles for Xbase Parts created
>                         as childs of a form object
>    XBPAPP_ALLSTYLES     Enable visual styles for all user interface
>                         elements
>    */
> 
> 
>    ...
> 
>    XbpApplication():enableVisualStyles := XBPAPP_DIALOGSTYLES
> =========================== snap =================================
> 
> This and the IVar :useVisualStyle introduced on the XbpWindow class
> (and thus on all derived classes) will give all control and flexibility
> for any case - existing applications and new applications.
> 
>  > depending on what you need, SL1 is not a "must have".
> 
> If you need to have your development tool up to date, SL1 is a must
> have. If you like to benefit from more then 140 closed PDRs and more
> then 170 new features and enhancements, SL1 is a must have. If you like
> to be preparred for the upcoming Artica technology and future releases
> of the VX system, SL1 is a must have. If you like to be preparred
> for new technologies and future Windows platforms, SL1 is a must have.
> Not going the SL1 road could be at least a little bit dangerous.
> 
> With my best regards,

Jan,

Thank you very much for your kind words. Personally, I am pretty sure
that SL1 is a good one - with improvements in many areas and fixes in
almost all modules. We have to appologize for not being able to
improve and fix everything 

We are anxiously awaiting the release date - which will be beginning
of next week according my latest information. Hopefully we will not find
any show stopper in our last preperation for release - keep the fingers
crossed.

If there is concern, we truely tried anything possible to clearify
any issue. From the beginning all important information was published -
any comment and suggestion went straight ahead into the next drop.
Personally, I think that the cooperation between the community and
Alaska Software in the SL1 newsgroup was fruitfull in wide areas.
To all of you who invested any time for any aspect regarding the SL1
preview: Thank you!!

If there are bad feelings - I have to admit that I understand your
point and I feel sorry that this issue is popping up so late.
(Issue := concern how to achieve "old" appearance). We have been the
opinion that everything required is explained in the readme and is
documented in the online help. If this would have been a discussion
during the preview stage we surely would have been able to add a
separate chapter in the docs regarding "migration" from 1.90.331 to
SL1. For sure, the readme and reference docs could have been extended.

 > But it is not communicated to the developers

Hm..... Obviously docs and readmes is not enough communication.....
So I have to agree.

Thank you for exchanging your thoughts.

With my best regards,

   Andreas Herdt
   Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

Jan Escholt wrote:
> Andreas,
> 
> thank you for pointing that out. Just let me say some words about that.
> 
> I can understand that some developers are concerned about: What will 
> happen to all my optical stuff in my apps if I change to SL1? I found my 
> own way to handle that, but I only need that to change that for my 
> browses. Other developers may need to do some more work.
> 
> Sometimes I can not understand the discussion about themes in SL1. A lot 
> of people asked very resolute for supporting themes in XP and Vista. Now 
> we do have this, and again it is wrong.
> 
> But: I also think that a lot of stress and bad feeling could have been 
> avoided if Alaska would have written some more about how to handle it a 
> bit earlier. A lot of the stuff Alaska is doing is good, we have waited 
> for it, we really need it. But it is not communicated to the developers. 
> The old problem.
> 
> Just my thoughts about that.
> 
> Jan
> 
> 
> Andreas Herdt schrieb:
>> Hi,
>>
>> The upcoming Service Level1 for Xbase++ 1.90 is clearly focused on
>> Windows Vista support. For this, a huge area of the underlaying
>> Xbase++ GUI engine was reworked. Furthermore a lot of new features
>> and functions have been introduced.
>>
>> It was important for us to enable you to adapt your existing application
>> to the enhanced visual appearance of the latest Windows platforms.
>> Furthermore, we had to decide about the default appearance when
>> new application are to be created. To us it was no question that
>> this must be the default appearance of the windows platform - a belief
>> other community members agreed to.
>>
>> At the same point of time we have been aware of the fact that
>> a lot of XbaseParts have been customized in beautiful applications.
>> It is our responsibility that existing code will not be broken
>> with new Xbase++ releases - at least we need to give a clear
>> statement if this is the case.
>>
>> So how to resolve this conflict?
>>
>> In case of the visual styles we decided to introduce an application
>> wide switch so you are able to achieve the accustomed behaviour. The new
>> class XbpApplication has an access assign IVar that gives you quite
>> fine control about the applications behaviour. Adding two lines of
>> code is an effort we think you can do when switching from one version
>> to another.
>>
>> =========================== snip =================================
>>    #include "applictn.ch"
>>    /* provides
>>    XBPAPP_NOSTYLES      Disable visual styles for the application
>>    XBPAPP_DIALOGSTYLES  Enable visual styles for forms and dialogs
>>    XBPAPP_CHILDSTYLES   Enable visual styles for Xbase Parts created
>>                         as childs of a form object
>>    XBPAPP_ALLSTYLES     Enable visual styles for all user interface
>>                         elements
>>    */
>>
>>
>>    ...
>>
>>    XbpApplication():enableVisualStyles := XBPAPP_DIALOGSTYLES
>> =========================== snap =================================
>>
>> This and the IVar :useVisualStyle introduced on the XbpWindow class
>> (and thus on all derived classes) will give all control and flexibility
>> for any case - existing applications and new applications.
>>
>>  > depending on what you need, SL1 is not a "must have".
>>
>> If you need to have your development tool up to date, SL1 is a must
>> have. If you like to benefit from more then 140 closed PDRs and more
>> then 170 new features and enhancements, SL1 is a must have. If you like
>> to be preparred for the upcoming Artica technology and future releases
>> of the VX system, SL1 is a must have. If you like to be preparred
>> for new technologies and future Windows platforms, SL1 is a must have.
>> Not going the SL1 road could be at least a little bit dangerous.
>>
>> With my best regards,

Andreas,

thank you for feeling my answer as "kind words" even if I told you that 
there has been another communication problem at Alaska 

But yes, I have to agree. There has been very good discussions in the 
SL1 NG. And I remember that sometimes Alaska changed some behavior in 
the SL1. Not only "little" things but also big stuff where Alaska 
changed everything because the community convinced you that the way you 
planed will not be axcepted. Even if I had some hard points with you the 
SL1 NG generally has been very effective.

But what I wanted to point out has been: I heard that with the final of 
SL1 you want to publish a "strategy paper" how to change existing 
projects from former Xbase++ versions to the SL1. Good idea. But why not 
publishing this before? Even if this paper would be a beta version? Now 
some (or many) users are feeling insecure about SL1. After hearing some 
rumours about all the stuff having been changed (you know, rumours base 
on truth, but are corrupted by the chinese post). I don't know how many 
developers really worked with SL1. But even this developers sometimes do 
have problems or questions with all the changes. Even if especially the 
themes stuff is well appreciated.

Don't mistake my words: Steffens paper on the 6 rules on OOP has been 
helpfull. Also all the other stuff you, Till and Steffen wrote in the 
SL1 NG explaining some stuff. But this concentrated migration paper 
should have been published much earlier.

Jan


Andreas Herdt schrieb:
> Jan,
> 
> Thank you very much for your kind words. Personally, I am pretty sure
> that SL1 is a good one - with improvements in many areas and fixes in
> almost all modules. We have to appologize for not being able to
> improve and fix everything 
> 
> We are anxiously awaiting the release date - which will be beginning
> of next week according my latest information. Hopefully we will not find
> any show stopper in our last preperation for release - keep the fingers
> crossed.
> 
> If there is concern, we truely tried anything possible to clearify
> any issue. From the beginning all important information was published -
> any comment and suggestion went straight ahead into the next drop.
> Personally, I think that the cooperation between the community and
> Alaska Software in the SL1 newsgroup was fruitfull in wide areas.
> To all of you who invested any time for any aspect regarding the SL1
> preview: Thank you!!
> 
> If there are bad feelings - I have to admit that I understand your
> point and I feel sorry that this issue is popping up so late.
> (Issue := concern how to achieve "old" appearance). We have been the
> opinion that everything required is explained in the readme and is
> documented in the online help. If this would have been a discussion
> during the preview stage we surely would have been able to add a
> separate chapter in the docs regarding "migration" from 1.90.331 to
> SL1. For sure, the readme and reference docs could have been extended.
> 
>  > But it is not communicated to the developers
> 
> Hm..... Obviously docs and readmes is not enough communication.....
> So I have to agree.
> 
> Thank you for exchanging your thoughts.
> 
> With my best regards,

hi,

> If you need to have your development tool up to date, SL1 is a must
> have. If you like to benefit from more then 140 closed PDRs

close PDR meen that Alaska have fix BUGs.
how much are include in v331 Hotfix 1-19 ?

> then 170 new features and enhancements,

if you count all Styleclass/Stylepart iVAR it might be correct,
but looking into Help file "what is new since v1.9.331"

*** quote ***
Erweiterte Untersttzung fr visuelle Stile unter Windows XP und Vista
Zustzliche Untersttzung des Owner-Drawing-Merkmals
Neue Klassen XppApplication, XbpApplication

Neue Funktionen zum Erzeugen von UUIDs
Neue Funktionen zum Erzeugen von Hashwerten
*** eof ***

exclude those "visual" Stff i just found XbpIcon, UUID,  Char2Hash() , 
RandomKey() and RandomInt()

>SL1 is a must have. If you like to be preparred for the upcoming Artica 
>technology

perhaps next Year ...

>for new technologies and future Windows platforms,

so you did have certificate Xbase++ for 64-bit Window7

> Not going the SL1 road could be at least a little bit dangerous.

same M$ say about VISTA

greetings by OHR
Jimmy

Jimmy,

Let me answer your considerations as follows.

 > if you count all Styleclass/Stylepart iVAR it might be correct,

Yes, indeed I count any single enhancement and improvement that made its
way to the SL1. Even an additional parameter sometimes means hard work
for several days. All of those positions is worth to be mentioned and
sum up in a total of approximatly 170. There is nothing wrong in in this
point of view.

 > but looking into Help file "what is new since v1.9.331"
 > *** quote ***
 > Erweiterte Unterstützung für visuelle Stile unter Windows XP und Vista
 > Zusätzliche Unterstützung des Owner-Drawing-Merkmals
 > Neue Klassen XppApplication, XbpApplication
 >
 > Neue Funktionen zum Erzeugen von UUIDs
 > Neue Funktionen zum Erzeugen von Hashwerten
 > *** eof ***
 >
 > exclude those "visual" Stff i just found XbpIcon, UUID,  Char2Hash() ,
 > RandomKey() and RandomInt()

You are right. The page "changes since Xbase++ 1.90.331" was handled
quite neglected. But this page also has a link "Changes in the
documentation" which leads to a complete list (Maybe we should change
the link to "for a complete List click here"). There you find a
systematic listing ordered by category that directly guides you to the
corresponding page in the documentation.

I doubt, that we will rework this part of the documentation if this
means a delay for the release.

 >>>>>>>>>>>>>>> side note >>>>>>>>>>>>>>>
For the SL1 participants who have worked through this list:
The SL1 final will carry a merge of new stuff from 1.82.294 to
1.90.331 and from 1.90.331 to 1.90.355. This was made to reflect
the SL nature of the release and for some technical reasons. However,
the SL1 stuff is prefixed accordingly. Also, the clospdr.lst file
will list all closed PDRs since 1.82.294 ordered by build level.
<<<<<<<<<<<<<<< side note <<<<<<<<<<<<<<<

 > close PDR meen that Alaska have fix BUG´s.
 > how much are include in v331 Hotfix 1-19 ?

Of course, we have also included the work done for the Hotfix Rollup
that have already been released for those Xbase++ programmers that
have been entitled for Hotfix Rollup access. But just for
clearification: Any fix that was published as Hotfix and Hotfix
Rollup was required to be qualified for the SL1. A Hotfix means the
fix for a single anomaly in a customer specific use case. In
many of the cases we stepped back to view the entire picture what
the anomaly means for the entire system. This sometimes concluded in
reimplementations of big parts of the codebase to taggle design
flaws that originally resulted in the anomaly. Furthermore, this
sometimes was done not solely for the SL1 codebase. The same
might have required a completely different approach for the upcomeing
2.0 codebase. Insofar, closing 66 PDRs for SL1 is not simply a copy
and paste job. Beyond of this, many more then those 66 PDRs have been
closed. Xbase++ has been improved in additional areas.

 > so you did have certificate Xbase++ for 64-bit Window7

You have tried Xbase++ SL1 on Windows7, right? The applications
came up and have been operational, right?

We will not officially support any operating system that has not
been released yet. This is no responsible behaviour. Indeed, we
have added Windows7 in our inhouse testing to be preparred for the
time when it is used in reallive installations.


With my best regards,

   Andreas Herdt
   Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------


AUGE_OHR wrote:
> hi,
> 
>> If you need to have your development tool up to date, SL1 is a must
>> have. If you like to benefit from more then 140 closed PDRs
> 
> close PDR meen that Alaska have fix BUG´s.
> how much are include in v331 Hotfix 1-19 ?
> 
>> then 170 new features and enhancements,
> 
> if you count all Styleclass/Stylepart iVAR it might be correct,
> but looking into Help file "what is new since v1.9.331"
> 
> *** quote ***
> Erweiterte Unterstützung für visuelle Stile unter Windows XP und Vista
> Zusätzliche Unterstützung des Owner-Drawing-Merkmals
> Neue Klassen XppApplication, XbpApplication
> 
> Neue Funktionen zum Erzeugen von UUIDs
> Neue Funktionen zum Erzeugen von Hashwerten
> *** eof ***
> 
> exclude those "visual" Stff i just found XbpIcon, UUID,  Char2Hash() , 
> RandomKey() and RandomInt()
> 
>> SL1 is a must have. If you like to be preparred for the upcoming Artica 
>> technology
> 
> perhaps next Year ...
> 
>> for new technologies and future Windows platforms,
> 
> so you did have certificate Xbase++ for 64-bit Window7
> 
>> Not going the SL1 road could be at least a little bit dangerous.
> 
> same M$ say about VISTA
> 
> greetings by OHR
> Jimmy 
> 
>

hi,

> sum up in a total of approximatly 170. There is nothing wrong in in this
> point of view.

right, a BUG is a BUG !!!
you also did not say that Hotfix 1-11 is from 2006 (!) and Hotfx 11-19 from 
2008

> A Hotfix means the fix for a single anomaly in a customer specific use 
> case.

but it is still a BUG and every Xbase++ can get into same Situation

Every Xbase++ User should get all BUGfix (Hotfix) for FREE or did you
see any other Company which make there User PAY for BUGfix ?

> "visual Style"

it just change "look & feeling" of your Xbase++ Application which nobody 
want.
so if a User have to use UseVisualStyle := .F. to get back "look & feeling",
why should i use SL1 ?

greetings by OHR
Jimmy

Jimmy,

you are right, a bug is a bug and has to be fixed upon the guarantee.

But, oh Jimmy,
 > it just change "look & feeling" of your Xbase++ Application which nobody
 > want.
 > so if a User have to use UseVisualStyle := .F. to get back "look & 
feeling",
 > why should i use SL1 ?
Why do you say this? So why don't go back to Clipper, or better: Just 
take your old Assembler. Jimmy,
we write software for Windows. So our software should work and look like 
Windows software should.

And SL1 is not only themes but a lot more.

You know that I always work with manifest, and I put that into my 
arc-file, not as a seperate file. OK, by doing this I force the user to 
have the look I provided. But that is fundamental with Windows. All 
programms should look the same as far as the themes provide this look. 
And I hate software that forces me to use a flashy, gaudy, surface with 
mouse cursors that are changed to one where you don't know where exact 
you are clicking. There are a lot of other possibilities to write a 
surface that is unique to YOU. But in my own oppinion software should 
allways give the opportunity to the user to give the software the look 
the user choose in the system control.

And I remember your brute force  against Alaska that you want to have 
the yellow bar on top of the tabpage. So why don't you want the themes 
right now? Or did I misunderstood?

Jan

AUGE_OHR schrieb:
> hi,
> 
>> sum up in a total of approximatly 170. There is nothing wrong in in this
>> point of view.
> 
> right, a BUG is a BUG !!!
> you also did not say that Hotfix 1-11 is from 2006 (!) and Hotfx 11-19 from 
> 2008
> 
>> A Hotfix means the fix for a single anomaly in a customer specific use 
>> case.
> 
> but it is still a BUG and every Xbase++ can get into same Situation
> 
> Every Xbase++ User should get all BUGfix (Hotfix) for FREE or did you
> see any other Company which make there User PAY for BUGfix ?
> 
>> "visual Style"
> 
> it just change "look & feeling" of your Xbase++ Application which nobody 
> want.
> so if a User have to use UseVisualStyle := .F. to get back "look & feeling",
> why should i use SL1 ?
> 
> greetings by OHR
> Jimmy 
> 
>

hi,

> > why should i use SL1 ?
> Why do you say this? So why don't go back to Clipper

ok lets start again: i ask for XPPSYS.DLL for v331.

i did use a lot of #IF XPPVER > 01900xxx for different Xbase++
Version. Now after "beta" testing SL1 i did begin to rewrite some
Source, i made with SL1, to "downgrade" to v331.

this is while i allways keep my Source compatible to:
Cl*pper v5.2e (if Hybrid)
Xbase++        (GUI)
harbour           (if Xbase++ fail)

in v331 i found ISTHEMEACTIVE() Problem again so i ask for XPPSYS.DLL

> we write software for Windows. So our software should work and look like
> Windows software should.

Yes, but our Xbase++ Application "look like" same since v1.3(?)

> And SL1 is not only themes but a lot more.

Neu: Funktion ComEvalCollection()
Neu: Funktion GetApplication()
Neu: Funktion GetPointerPos()
Neu: Funktion GraBackground()
Neu: Funktion GraEdge()
Neu: Funktion GraGradient()
Neu: Funktion GraSegLoad()
Neu: Funktion GraSegSave()
Neu: Funktion IsUnicode()
Neu: Funktion Str2Unicode()
Neu: Funktion TranslateSysColor()
Neu: Funktion UIThreadId()
Neu: Funktion Unicode2Str()
Neu: Funktion XbpFromPoint()
Neue Funktion Char2Hash()
Neue Funktion RandomInt()
Neue Funktion RandomKey()
Neue Funktion UuidCreate()
Neue Funktion UuidFromChar()
Neue Funktion UuidToChar()

these are the new Function, did i miss any ?

ok there are also new Methode like :showBallonTip() or :cueBanner()
but dont tell us that is "world new"...

> And I remember your brute force  against Alaska that you want to have
> the yellow bar on top of the tabpage. So why don't you want the themes
> right now? Or did I misunderstood?

that was the first Time i recognize that "something" with XbParts for
Windows is wrong. Under XP with Manifest our software does not look
like other Windows software and begin to ask why ?

Alaska does not explain us what is going on, just say it is a lot of work to
do for it... they do not tell us 2006 that Xbpart can not "visual Style"
that Way but it seems me also a Problem what Controls Alaska use
for XbParts like XbpTabpage ?

i did a lot of searching for Tabpage and i found out there are a lot of
different Tab"Page", Tab"s" and Tab"Control" for Windows. now after
a lot of activeX and "Tabs" i think i got it :

XbpTabpage() is not a real M$ Windows Control  ?!

it seem?s me like XbpBrowse() is a Alaska Construction or it is based of a
"very old" Control which make a "single" Tab"Page". but like Radiobutton you
will never have only one Tab"Page".

so Xbase++ contain a lot of "old Source", as Alaska say, which have to be
rewritten into new Source and add iVAR StyleClass and StylePart to every
XbParts as you can see it in Debugger.

i just wonder why Alaska did not use the Chance to get rid off all those
2D XbParts and upgrade to 3D Controls which use DX9 Hardware
accelleration like in Win7 ?

so every Xbase++ Application before SL1 are all "wrong" and does not
look like Windows software should. But our Customer are used to it !!!

it is like ME or VISTA, Customer do not like it so no need for it.

if Customer realy want to change Theme they can use activeX Codejock
Skinframework if you fix ISTHEMEACTIVE() in v331 which is the Topic
of the Thread

greetings by OHR
Jimmy

But that is not part of 331 it is part of SL1. The major purpose of SL1
is to fix these rendering problems in 331. Back porting a small part of
SL1 to 331 simply does not make any sense.

Jim

AUGE_OHR wrote:
> hi,
> 
>>> why should i use SL1 ?
>> Why do you say this? So why don't go back to Clipper
> 
> ok let´s start again: i ask for XPPSYS.DLL for v331.
> 
> i did use a lot of #IF XPPVER > 01900xxx for different Xbase++
> Version. Now after "beta" testing SL1 i did begin to rewrite some
> Source, i made with SL1, to "downgrade" to v331.
> 
> this is while i allways keep my Source compatible to:
> Cl*pper v5.2e (if Hybrid)
> Xbase++        (GUI)
> harbour           (if Xbase++ fail)
> 
> in v331 i found ISTHEMEACTIVE() Problem again so i ask for XPPSYS.DLL
> 
>> we write software for Windows. So our software should work and look like
>> Windows software should.
> 
> Yes, but our Xbase++ Application "look like" same since v1.3(?)
> 
>> And SL1 is not only themes but a lot more.
> 
> Neu: Funktion ComEvalCollection()
> Neu: Funktion GetApplication()
> Neu: Funktion GetPointerPos()
> Neu: Funktion GraBackground()
> Neu: Funktion GraEdge()
> Neu: Funktion GraGradient()
> Neu: Funktion GraSegLoad()
> Neu: Funktion GraSegSave()
> Neu: Funktion IsUnicode()
> Neu: Funktion Str2Unicode()
> Neu: Funktion TranslateSysColor()
> Neu: Funktion UIThreadId()
> Neu: Funktion Unicode2Str()
> Neu: Funktion XbpFromPoint()
> Neue Funktion Char2Hash()
> Neue Funktion RandomInt()
> Neue Funktion RandomKey()
> Neue Funktion UuidCreate()
> Neue Funktion UuidFromChar()
> Neue Funktion UuidToChar()
> 
> these are the new Function, did i miss any ?
> 
> ok there are also new Methode like :showBallonTip() or :cueBanner()
> but don´t tell us that is "world new"...
> 
>> And I remember your brute force  against Alaska that you want to have
>> the yellow bar on top of the tabpage. So why don't you want the themes
>> right now? Or did I misunderstood?
> 
> that was the first Time i recognize that "something" with XbParts for
> Windows is wrong. Under XP with Manifest our software does not look
> like other Windows software and begin to ask why ?
> 
> Alaska does not explain us what is going on, just say it is a lot of work to
> do for it... they do not tell us 2006 that Xbpart can not "visual Style"
> that Way but it seems me also a Problem what Controls Alaska use
> for XbParts like XbpTabpage ?
> 
> i did a lot of searching for Tabpage and i found out there are a lot of
> different Tab"Page", Tab"s" and Tab"Control" for Windows. now after
> a lot of activeX and "Tabs" i think i got it :
> 
> XbpTabpage() is not a real M$ Windows Control  ?!
> 
> it seem?s me like XbpBrowse() is a Alaska Construction or it is based of a
> "very old" Control which make a "single" Tab"Page". but like Radiobutton you
> will never have only one Tab"Page".
> 
> so Xbase++ contain a lot of "old Source", as Alaska say, which have to be
> rewritten into new Source and add iVAR StyleClass and StylePart to every
> XbParts as you can see it in Debugger.
> 
> i just wonder why Alaska did not use the Chance to get rid off all those
> 2D XbParts and upgrade to 3D Controls which use DX9 Hardware
> accelleration like in Win7 ?
> 
> so every Xbase++ Application before SL1 are all "wrong" and does not
> look like Windows software should. But our Customer are used to it !!!
> 
> it is like ME or VISTA, Customer do not like it so no need for it.
> 
> if Customer realy want to change Theme they can use activeX Codejock
> Skinframework if you fix ISTHEMEACTIVE() in v331 which is the Topic
> of the Thread
> 
> greetings by OHR
> Jimmy 
> 
>

hi,

> But that is not part of 331 it is part of SL1. The major purpose of SL1
> is to fix these rendering problems in 331.

Yes, i now using fixed "XbpParts.prg", which is in v331 as Source too.

> Back porting a small part of SL1 to 331 simply does not make any sense.

i ask if it is possible to use a "XPPSYS.DLL" like SL1 for v331 too,
while OOP-model in 1.90.331 is different from SL1.

if i create a DLL for v331 called "XPPSYS.DLL" in my *.XPJ it seems
not to "override XppRT1.dll" (in 1.90.331) ? Code work if include in EXE !

so i try to use 1 Version of Source, which my modification and XPPVER
in a DLL called "XPPSYS.DLL" for v331 and SL1.

is this possible ?

greetings by OHR
Jimmy