View Full Version : Compatibility settings
NewsArchive
07-30-2007, 03:10 AM
Does anyone know when Friedrich will be back? I am particularly keen to
check out the new Compatibility Settings code he was discussing just before
he went on vacation.
I have a release of my software going out in the next few days and wondered
if a SB update was imminent.
TIA
John Fligg
NewsArchive
07-30-2007, 03:11 AM
turn your eyes down a bit ...July 20-28 ....
JP
--
Merci - Thank you
JP
NewsArchive
07-30-2007, 03:57 AM
John,
A new SetupBuilder release is nearly ready to ship. This build will support
the new "Set AppCompatFlags..." script function.
Friedrich
--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910
"point. click. ship" - that's SetupBuilder 6.5
Create Windows Vista ready installations in minutes
-- Official Comodo Code Signing and SSL Certificate Partner
NewsArchive
07-31-2007, 05:49 AM
Thanks Friedrich - you're a star. But you knew that anyway didn't you.
John
NewsArchive
07-31-2007, 05:50 AM
Hi John,
How will you be using this feature? Just curious.
Lynn Howard
NewsArchive
07-31-2007, 05:50 AM
Lynn
I find that sometimes when running an app with MakeOver applied under Vista,
radio buttons and checkboxes lose their transparecny properties. We have
never really found out why.
I did however find that by setting an application to run under Windows XP
compatibility mode, nothing is affected but the transparency issues
immediately disappear.
Hence the need for this feature.
HTH
John
NewsArchive
07-31-2007, 05:50 AM
Hi John,
My issue exactly. What version of Clarion are you using. Mine is 9029.
Bruce worked diligently with me on this and we never found a solution.
I find that simply checking the exe's Disable Visual Themes in Vista does
the trick without running in compatibility mode. Will that work for you?
Lynn
NewsArchive
07-31-2007, 08:27 AM
I am using 9053 - so much later than yours and still the same issue.
I worked with Capesoft for some time on this too but never got a final
solution.
I prefer to use Vista with NO changes as getting my users to turn stuff off
is a nightmare, so a solution right out of the box is much better. The
changes friedrich has made seems to be the best solution.
HTH
John
NewsArchive
07-31-2007, 08:27 AM
Hi John,
My question is changing the Display Themes better than running in
compatibility mode? I believe the SB update will allow that also.
BTW I am using Legacy.
Lynn
NewsArchive
07-31-2007, 08:27 AM
Sorry I misread the3 post.
Well I guess the answer is YES. However I need to use transparency (for now)
as I prefer to use different coloured windows for different finctions.
John
NewsArchive
07-31-2007, 10:14 AM
The downside to using a compatibility mode is if your app needs to detect
what OS it's running under.
For example, if you do anything different under Vista (such as location of
your INI or data files or registry writes), your app's OS detection will
return an incorrect version if you're using a compatibility mode.
Jane
NewsArchive
07-31-2007, 10:15 AM
Hmmmm - I put my ini files (and data etc.) under a CSIDL folder.
They are declared in the app using aglobal variable i.e. GLO:DataPath etc.
Surely this would not be affected?
John Fligg
NewsArchive
07-31-2007, 10:15 AM
You're right, John.
I don't see the CSIDLs affected by compatibility mode.
What I intended to refer to is if you're actually detecting the version
using something like the GetVersionExA API call. That will return the
compatibility setting, rather than the actual OS version.
Jane
NewsArchive
07-31-2007, 10:15 AM
So why can't you use Disable themes on the Compatibility tab? Displays just
fine then for me.
Lynn
NewsArchive
07-31-2007, 10:15 AM
If it works fine, Lynn, it works fine.
I just wanted to point out that if your app actually needs to detect the OS
version, it will be fooled by setting compatibility to a different version.
That's actually one of the main purposes of the compatibility setting.
Jane
NewsArchive
07-31-2007, 10:57 AM
Thanks Jane,
I was wondering if that worked for John.
Lynn
NewsArchive
08-01-2007, 02:08 AM
Jane and JohnF
One thing I have been pondering....
If I use CSIDLs for setting ini/security file type file and the customer installs and
runs a WinXP PC .
Three months later, he/she applies an UpGrade from WinXP to Vista
Are not now all the CSLIDs going to be screwed up?
The ini file may be in where CSLID points to, that being
C:\Documents and Settings\AllUsers\MyProg\MyINI.INI
from when my program was installed and he was running XP.
Oliver Sudden the program starts up and Vista is in control. Vista now says that the
INI file should be at
c:\ProgramData\MyProg\MyINI.INI
Won't this mess up my program settings/security?
JohnG
NewsArchive
08-01-2007, 02:08 AM
John
This is precisely what I do now. I provide a SB install for anyone (assumes
XP or Vista or beyond). I do NOT support Win98 for various reasons and the
CSIDL issues.
In my program startup I assign various global variables such as ini path,
data path, images etc. Basically any files that the user can change go to a
CSIDL folder.
Then in various template extensions, I assign the global name as the ini
filename and not harcode it.
In that way, the user can move the application from XP to Vista with no
problems at all. The only thing they have control over is where to install
the application files which by default is Program Files ....
BTW Current users runnning on an XP box have the data folders as a subfolder
of the application with ini files in the application path. I have spent a
month writing and testing a conversion program to copy the application and
split all the files to Vista compatible locations even on an XP box. No mean
feat, but it does mean that whatever happens, my users are now either Vista
compatible or if they change from XP to Vista will be with very little to
change (if anything).
HTH
John Fligg
NewsArchive
08-01-2007, 02:09 AM
Phew! <g> You had me worried there.
Back to the drawing board then with this Makeover issue then. However just
to confirm that the compatibility mode does actually fix it, if not ideal.
Thanks.
John
NewsArchive
08-03-2007, 04:19 AM
John
Yes, but...
What I was trying to say was that a particular CSIDL will point to one path on XP, but
to a completely different folder path on Vista.
Perhaps the Windows OS upgrade from XP to Vista process is smart enough to move your
ini files appropriately. But I doubt it.
JohnG
NewsArchive
08-03-2007, 04:19 AM
I am not sure about the different path but if you say so then fine. I have
never checked that out.
However, so long as the installer is using the CSIDL value then surely all
must be OK?
In my updater installer (converting from XP to Vista) I simply (not that
simply <g>) use the CSIDL value on the XP box and copy everything to the
same CSIDL value on the Vista box. The fact that the paths are different
should not matter so long as everything relatively is the same.
In the code itself, I do the same by using the CSIDL value to define the
global variables using Winevent. That means that whichever file is being
located is to be found at the CSIDL value of that particular machine.
It took me about 2 weeks to get all this into my head and then realised that
so long as my clients use my installer to convert from XP to Vista all will
be OK. If they just copy the same folders across then they will be in
trouble. Especialyl as most of my clients hardly even know what a computer
is <g>
Bottom line though seriously is that so long as your code is using the CSIDL
value for the global variables as the path name to each set of files, then
it should not matter if it is XP or Vista.
HTH
John
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.