Window differences between Ver. 6 and 10

[HwyStar]

I am updating my WMS from Clarion version 6 to 10. Finally! It has been a great run using version 6.

The windows below look different. The first window is from my production environment. I put a STOP right after I opened the window and did a DISPLAY too. There is nothing in my code to eliminate the brown color of the SHEET control like the second window below.

This second window is from my development environment and it looks like it should. But this window is also using version 10 just like the production environment!

I am scratching my head on this one! My SHEET control code for this window:

EOH WINDOW(‘EOH: Order Header Edit’),AT(,451,276),CENTER,GRAY,AUTO,SYSTEM, |
ICON(‘C:\Dev\ICONS\hdc.ico’),STATUS(320,-1),FONT(‘Tahoma’,8,FONT:regular), |
TIMER(100),ALRT(Alt0), ALRT(AltT), ALRT(F12Key)
SHEET,AT(11,4,427,251),USE(?SHEET1),SPREAD,COLOR(0C1D7DDH)
TAB(’&Logistics’),USE(?TAB1)
blah, blah, blah…

1. Is this a Windows 32 bit vs 64 bit issue? We are using Windows Server 2008 R2. Most of our workstations are 64 bit.

2. I am compiling both versions using Windows 7 - 32 bit. Clarion 6 only worked with 32 bit.

3. I am not using DLL’s. Everything is compiled as local, standalone exes.

4. Has something in the threading model changed to cause color issues? This windows is called from an APPLICATION.

5. Could this be a stack issue?

But why does development look correct and production does not! I cannot think of anything that would cause this issue.

THANKS FOR YOU HELP (If you can offer any)!

Best,
Robert

[brahn]

Sounds like maybe the manifest file is not being embedded?

Check the directory where you compile the EXE and look for a file called something like YourAppName.exe.manifest. If you take that file and put it in the same folder as the EXE in production you should see the difference (restart the app of course ). Then you need to either ship the manifest file with your app or tick the “Link Generated Manifest in Project” global option:

Play around with the options until you get something suitable.

[HwyStar]

That sounds like a good idea Brahn!

Now, because this is a hand-coded project/solution where do I go about setting that since this isn’t an application?

I read up on the MANIFEST VISTA WINDOWS7 statement in the help text. It makes sense to at least try the WINDOWS7 statement. We are using Windows 7 workstations throughout our domain.

Where would I insert that directive statement ? The help text does not tell the user where to insert these statements to be linked in by the linker. I don’t think it goes in the “Conditional Compilation Symbols” section. There isn’t a Clarion Global Properties window that I can tell when using a hand-coded project. Would it go in the exe.cwproj file?

Thanks Brahn!

=====================================================================================
Clarion Help Text:
The MANIFEST statement

MANIFEST [file name] [VISTA] [WINDOWS7]

This directive instructs the linker to add specified manifest file name to the executable. If the manifest file name is omitted, the linker adds a default manifest. If both the project file and the EXP file contain directives to link the manifest file, the one specified in the project file will be used.

If the MANIFEST directive has a file name parameter, the optional VISTA and/or WINDOWS7 parameters are ignored and the linker uses the manifest from the file (file name) parameter. If the file name file does not exist, an error is reported.

If the MANIFEST directive has no file name parameter, the linker adds the default manifest to the executable. If neither VISTA nor WINDOWS7 parameters are present, the linker adds default manifest compatible with Windows Vista.

If either or both of VISTA and WINDOWS7 parameters are present, the linker adds the manifest with the new compatibility section introduced in Windows7. If the MANIFEST directive has just the VISTA parameter, the manifest includes the record indicating that the application supports Windows Vista. If the MANIFEST directive has the WINDOWS7 parameter, the manifest includes the record indicating that the application supports Windows7.

Examples:
MANIFEST VISTA some.manifest
The manifest is taken from the some.manifest file; the VISTA parameter is ignored

MANIFEST VISTA WINDOWS7
The linker adds to the executable the default manifest compatible with Windows7 which includes records indicating application compatibility with both Windows Vista and Windows7

MANIFEST
The linker adds the default XP/Vista-compatible manifest

[brahn]

Check out this topic where I have applied a manifest to Marks example:

How to Alter the Icon of a COMBO drop control

Hey @MarkGoldberg, thanks for the demo! I had a quick play around because I wanted to see what it looked like. For anyone else wanting to compile the example go and grab the dependencies from Marks github repo - ClarionCommunity Specifically you want these: debuger.inc debuger.clw TUFO.INT FileAccessModes.EQU …however your life might be easier if you just grab the whole repo and setup your RED to point to the appropriate paths! I did notice one thing Mark, and I am curious to hear if you h…

@brahn

In my EXP I had:

MANIFEST VISTA WINDOWS7 combobutton.exe.manifest

[lchudakov]

Hi Robert,

If the second screenshot is what you need then I think you need to disable manifest for your app
Also check what’s Sheet’s Tab Control style is set to under Extended UI button

HTH
Leonid

[brahn]

Oh yes, I miss interpreted the OP. My response was to include a manifest but if you don’t want themed controls then that will do the opposite! Could it be you have ‘classic’ desktop theme enabled on your development desktop?

[HwyStar]

Thanks for your help Leonid and Brahn!

So I added main.exp to the project in the “Libraries, Objects and Resource Files” section of the Solution Explorer. Now I understand what that is used for. This is where you add *.exp files to a hand coded project. We didn’t have to mess with this in V6 since Vista did not exist then.

So, after I included the main.EXP file into the linking process then development started acting like production where the SHEET control was NOT brown colored. If I removed the main.exp from the solution the window still acted incorrectly. So then I renamed main.exp to main.bck and the SHEET control was now tan colored. Interesting…

The main.exp file is impacting the way the SHEET control works, in a bad way. And why a compiled exe in development that works correctly, without the exp file being compiled in, then is copied into production and it does not work is a mystery.

Brahn: I am not using Classic Desktop Theme. I double checked myself on that. Thanks!

Leonid: I formatted the window from the code and the SHEET control has the property setting of UseVisualStyles. I turned that to false on the designer and it now showed the tan colored SHEET in designer. I went to the help text for UseVisualStyles and it talks about that if you want the MANIFEST to be in XP mode to set it to false. The plot thickens Bat Man…

I did try compiling the program with just the MAINFEST statement in the main.exp file. The help text says that this will compile the exe using XP/Vista mode. I may try setting the manifest statement to MANIFEST XP and see what happens. I don’t know if that is supported.

Vista, on up in operating systems must have changed the embedded objects used by all compilers for the SHEET control. It also talks about the COMBO and LIST controls as being impacted by UseVisualStyles. I got a GPF using a very large COMBO control so something changed in the OS. I converted the COMBO to a LIST and everything worked fine. There must now be two different COMBO,LIST and SHEET controls in the later OS’s now. Legacy and current.

I will report back here what my final solution becomes. I appreciate your help guys and I think I am on the correct path now.

I may just need to reformat all my windows with a colored tan background on the WINDOW statement and make all the child controls transparent.

Thanks again guys for the speedy help!

[seanh]

C10 windows theme works very differently to C6. If you look at the screen shot from Brahn down the bottom are 3 check boxes for how things work on tabs. You will need to play with those I think to get things fixed.

[HwyStar]

Thanks for pointing that out Sean!

The problem is, is that I do not use Applications. It is a hand coded project. Now if you know of a way to turn those switches on/off via a hand coded project then that would probable solve it for me!

This weekend, when no one is around and I can test in our production environment, I will be trying to flip every switch I can find to see what the issue is or if I can resolve it - real time.

I will look in the documentation to see if the application switches you mention Sean are documented some where to be enable/disabled for my kind of project. Thanks again Sean!

[HwyStar]

Question for you guys: Do you have a Platform: Win64 option on your projects compile window? All I have is Win32 like this screen shot:

I am using a Windows 7 - 32 bit OS since V6 only worked on 32 bit.

[HwyStar]

I think I found the answer in the help text:
PROP:NoTheme can be applied to a SHEET control. It prevents the Operating System theme color from being applied to the SHEET /TAB controls allowing you to set the Colors.

I will try this tomorrow!

[seanh]

I found this in the template
#IF(%ForceSHEETNoTheme)
#FOR(%Control),WHERE(%ControlType=‘SHEET’)
%Control{PROP:NoTheme} = True
#ENDFOR
#ENDIF

So looks like thats the way

[HwyStar]

Outstanding find Sean! Thanks Man. This will be my first try at an easy solution. I will report tomorrow or Sunday. Thanks again guys!

[HwyStar]

Excellent!

Prop:NoTheme works as planned for hand coded projects to eliminate SHEET controls from allowing the OS to take charge of a colored sheet. Thanks again for the help guys! Off I go!!!
!===========================================================================================
CODE

OPEN(WINDOW)
?SHEET1{PROP:NOTHEME} = TRUE