It works perfectly on my app, I have the admin rights now elevated, but when I drag and drop a picture on a picture box it does not work, what is the problem? please tell me.
It works perfectly on my app, I have the admin rights now elevated, but when I drag and drop a picture on a picture box it does not work, what is the problem? please tell me.
Ummm, what does your drag/drop problem have to do with this manifest creator? You are making an assumption, right or wrong, that permissions are involved with your problem. Post your question along with some code snippets in the appropriate portion of the forums.
Please use this thread to only post questions/information relevant to the project I provided. Otherwise, the CodeBank section is not the place to post non-related questions. Thank you.
Insomnia is just a byproduct of, "It can't be done"
Nice project LaVolpe. I wonder if the version or appname make any difference. For example, I created a resource using your tool called VisualStyles.res ver 1.0.0.0. I have several vb projects so I simply add this res file to each VB6 project and modify the SubMain.
I can't see that the version or name make any difference. Are they important?
Yes, the application section. I have not seen any issues relating to uniqueness, but it may be there. I'm also finding that just placing a manifest file in a dir doesn't work anymore for one of our non VB apps on Win 7.
I'm also finding that just placing a manifest file in a dir doesn't work anymore for one of our non VB apps on Win 7.
Not sure what to tell you. As we all know, what used to work before may not work on newer systems. When in doubt, I always side with the creator's advice (Microsoft in this case). And this is the reason why the option to provide that information exists in this project. Will changing that info in your manifest fix it? Easy enough to test & rule out for your situation. I'd also verify the manifest is in line with the link(s) in post #2 to rule out improper format/content.
Insomnia is just a byproduct of, "It can't be done"
Thanks for providing this creator. Looks much better than plain VB6.
Please note the following:
1) Option buttons in Frames look fine in Win 7 and Vista. Only get blacked out in XP.
2) Adding the security section seems to cause problems in Win 7 (and I expect Vista). It stopped my app from creating a file correctly in the users document folder (standard user with no special admin rights under Win7). It also wouldn't remember (save) the Armadillo security key entered. It would forget the key each time the app was restarted. These problems disappear if I don't use the security feature (invoker).
2) Adding the security section seems to cause problems in Win 7 (and I expect Vista). It stopped my app from creating a file correctly in the users document folder (standard user with no special admin rights under Win7). It also wouldn't remember (save) the Armadillo security key entered. It would forget the key each time the app was restarted. These problems disappear if I don't use the security feature (invoker).
Almost certainly due to the program working properly (with the trustInfo) instead of with filesystem and registry virtualization.
Of course "properly" here means following the rules which restrict where programs can write to. If your programs are not Vista-aware then they need the virtualization appcompat shims, and so cannot have a trustInfo section. The presence of trustInfo (no matter the requestedExecutionLevel setting) is an explicit declaration to Windows that you are Vista-aware. Legacy programs need to omit this section.
A user's Documents folder is not a restricted location. Perhaps your program is using an old-format hard coded path?
2) GDI+ v1.1 dependency. GDI+ v1.1 is available on Vista and above, VB will not use it by default without a .Local file or by requiring it in a manifest. There is a big caveat here. Including this in a manifest where the app will also be deployed on XP will prevent the app from loading when installed on XP. This is because GDI+ v1.1 is not available on XP. There is one exception. One known version of GDI+ v1.1 does work on XP, but the odds that it exists on every machine you want to deploy your app is extremely remote. Also, v1.1 is not redistributable.
With the above GDI+ v1.1 warning supplied, there is a workaround where your app can use a manifest and load GDI+ v1.1 on Vista and above, but not try to load it on XP. Here's that workaround:
- Create a manifest that includes the v1.1 dependency. Embed this manifest into a resource file so it is compiled with your application
- Create a second, identical manifest that excludes the v1.1 dependency. Save it to file named exactly the same as your application but adding a .manifest extension.
Now when you build your deployment package (i.e., setup.exe), you will include that manifest file too. When installing on XP, you must deploy that manifest file to the same folder as your application. When installing on Vista and above, you do not want to include that manifest file
This is how the workaround works. On XP, external manifests override embedded manifests. On Vista and above it is the opposite behavior. However, there is a registry setting that can force the behavior to be same as XP. So, since the manifest file is deployed in XP and that file does NOT include the v1.1 dependency, your XP app will work just fine because the embedded manifest is overridden by the file. And by not deploying the file on Vista and above, you do not need to be concerned with it overriding the embedded manifest which does include the v1.1 dependency. On Vista and above, this concern only applies if that registry setting is set; otherwise external manifests do not override embedded manifests
Last edited by LaVolpe; Jan 25th, 2012 at 04:39 PM.
Insomnia is just a byproduct of, "It can't be done"
Applying the info in the previous reply, here is how you can run VB6 IDE using some manifest options
The manifest below will tell Vista & above, that VB6 is DPI-aware, to use themed controls, and to use GDI+ v1.1, all of which, are optional and can be removed from the manifest. By placing a copy of this manifest in the same folder as VB6.exe, it will be used when VB6 is run. To stop it from being used, simply rename the manifest file to something else.
FYI: Why care if v1.1 of GDI+ gets loaded instead of v1.0? Simply, you may be using custom controls that offer extra stuff if v1.1 is loaded. You may want to use v1.1 functions when on Vista+
For XP: You will need to change the GDI+ version from 1.1.0.0 to 1.0.0.0 otherwise VB will not load if GDI+ v1.1 does not exist on the XP machine. The other sections and entries are fine.
For Vista & above. I have noticed that when disabling the manifest by renaming it & then naming it back so it could be used, it seems to be ignored from time to time. There is some system caching going on and this is one way around it.
a) Close any instances of VB6
b) Right click on VB6.exe & select Properties
c) Toggle the Compatibility option's checkbox
d) Click the Apply button
e) Toggle that Compatibility option's checkbox again
f) Click the Ok button
g) Re-start VB6, the manifest should now be effective once again
This can be copied and pasted into a text document, then renamed to vb6.exe.manifest
I understand why you'd want to select the newer GDI+ assembly for programs written for Vista or later. But I assume that's because you want to use that version's newer capabilities.
Since it doesn't exist in most cases in XP though, how can you just use the older assembly? Your calls wil fail?
Or are you additionally expecting the program to be written to use error trapping around a "test call" to some 1.1 function to set a flag causing the program to skip using 1.1 calls from then on?
Also, if some program is found fiddling with an important global registry setting like that one you mentioned I'd consider it malware. This isn't the reputation you want any of your software getting.
As far as I can tell, the proper way to handle this sort of thing would be to avoid selecting this assembly via the manifest. Instead you could use the SxS calls after testing the version of Gdiplus.dll or the OS version.
But I'm no GDI+ expert, and certainly not 1.0 vs. 1.1 literate. Not trying to drag this off topic, but I see:
Note If you are redistributing GDI+ to a downlevel platform or a platform that does not ship with that version of GDI+ natively, install Gdiplus.dll in your application directory.
But maybe that's just the 1.0 version of the library?
I wouldn't put it in the application directory (bad, bad advice there with nasty potential consequences for VB6 programs) nor use a .local file (completely obsolete). But one can easily put it into a subdirectory of the application's directory to isolate it, and then have the manifest for the application redirect to it there.
You use the loadFrom attribute of the <file> tag to do this, the value of this attribute is a relative or absolute path to the redirected, isolated library.
Last edited by dilettante; Jan 26th, 2012 at 12:55 AM.
It does look like the redist Gdiplus.dll is a 1.0 "edition" (hate to call it "version" since the versioning is different from this) meant to go onto Win2K and such. There also seems to be an unrelated "1.1" that some versions of Office install into XP, but it isn't supposed to be generally usable.
I had no beef with your last post until it started talking about hacking global registry settings. I still think there is a preferable way to do this, but I concede that they won't be of any help for the VB6 IDE. You have to use a manifest there, and for Vista+ programs that's a fine solution anyway.
Things only start getting dicey if you want a program to use 1.1 after XP but still run in crippled (1.0) mode on XP.
Last edited by dilettante; Jan 26th, 2012 at 01:10 AM.
- Hacking registry. I wasn't supporting that at all, you misread my intentions. I wanted those interested to know that users (read pc owners) can override default behavior in Vista+. This information is useful to know if you expect your embedded manifest to always be used. Knowing this would also be helpful for troubleshooting
- v1.1 of GDI+. In stuff I build, it is easy enough to test for the version. So I set a global flag. If the flag is set, other options are enabled in the software. If not, they are disabled. I have no knowledge of any function/method corrections between the two dlls, but if there were & there probably are, this would be another reason to want the newer version.
-- update this last point. v1.1 on Vista, Win7/8 do have corrections to v1.0 functions. GDI+ LoadImagexxx functions in later O/S version of v1.1 fixed some bugs that existed in earlier v1.1 & v1.0
Last edited by LaVolpe; Aug 30th, 2014 at 07:44 PM.
Insomnia is just a byproduct of, "It can't be done"
I see what you mean. I've definately had people do this and break applications by substituting a bad file manifest. Lots of frustration trying to figure out what went wrong.
As far as GDI+ 1.1 goes, as far as I can tell the main changes were moving a few operations out of GDI+ itself and into the DWM. Beyond that I've seen little.
GDI was enhanced in Win7 to use hardware acceleration for a few things like blitting, while GDI+ has been left behind. The "way forward" is supposed to be Direct2D now. But not being a graphics guy I haven't messed with any of it in a meaningful way.
It's all a rat's nest to me. I just hate wasting time debugging something caused by a registry tweak.
Didn't think I'd mess with this again, but appears to have quite a few references on several other sites, not just this one. So, wanted to add O/S compatibility options to manifests for those that still use & abuse this project. Update includes that and more. See the change history in the 1st post, where you would download the project from.
Note: Not yet fully tested with Win8/8.1 so if others that play with this can post any issues, I can see what I might be able to do about it.
Edited: found what appears to be a valid Win10 compatibility GUID. Will add that to the manifest creator after a bit more research.
Code:
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
Another modification would be for win8.1 that has a 'per monitor' DPI-awareness flag
Code:
<dpiAware>True/PM</dpiAware>
Last edited by LaVolpe; Nov 17th, 2014 at 02:22 PM.
Insomnia is just a byproduct of, "It can't be done"
As far as I can determine those <supportedOS /> entries just turn off some appcompat shims and turn on other things (like correct version reporting).
So it seems as if most people won't need them, though some certainly will if they want and need accurate version reporting.
Vista ignores the "Vista" value. Win7 may pay attention to it (though this doesn't seem clear), hard to say beyond that. I think each post-Vista OS version only looks for its own, assuming you have a <trustInfo /> node.
So far I can't find a list of things for each OS that the compatibility entry turns on or off. About all I've seen that even attempts to discuss the topic is Manifesting for Compatibility on Windows 7 but I haven't been keeping up with SDKs anymore either.
Yep, from what I can gather, it may effect quite a bit...
Originally Posted by msdn
The Compatibility section allows Windows to provide new behavior to new developer-created software while maintaining the compatibility for existing software. This section also helps Windows deliver greater compatibility in future versions of Windows as well. For example, an application declaring support only for Windows 7 in the Compatibility section will continue to receive Windows 7 behavior in future version of Windows.
Applications without a Compatibility section in their manifest will receive Windows Vista behavior by default on Windows 7 and future Windows versions. Note that Windows XP and Windows Vista ignore this manifest section and it has no impact on them.
Just a FYI item. Another benefit of adding manifests is the ability to add nice alpha-blended icons to your buttons. This method will NOT work if controls are not themed.
The button icon assignment in the screenshot below was accomplished with a couple lines of code
1) Load your alpha-blended icon via your favorite method. You will need to destroy the icon at some point
2) Here are the APIs
Code:
Private Const BM_SETIMAGE As Long = &HF7&
Private Declare Function SendMessage Lib "user32.dll" Alias "SendMessageA" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByRef lParam As Any) As Long
Private Declare Function DestroyIcon Lib "user32.dll" (ByVal hIcon As Long) As Long
3) Here's the simple assignment after you've loaded your icon
Hi LaVolpe, i know this is an old tool but good work by the way.
I came across this thread by accident really and i have a question for you?
I tried your Manifest creator on an old VB6 progam we have at my work which we don't really wont to upgrade just yet and while it updates the look and feel of buttons and text boxes it does nothing to the Listviews & Toolbars.
Is this expected? should they skin or not?
Last edited by NeedSomeAnswers; Jun 25th, 2015 at 04:56 AM.
Please Mark your Thread "Resolved", if the query is solved & Rate those who have helped you
Hi LaVolpe, i know this is an old tool but good work by the way.
I came across this thread by accident really and i have a question for you?
I tried your Manifest creator on an old VB6 progam we have at my work which we don't really wont to upgrade just yet and while it updates the look and feel of buttons and text boxes it does nothing to the Listviews & Toolbars.
Is this expected? should they skin or not?
Depends on which version of the common controls you are using. v5 is 'skinnable' v6 is not
Insomnia is just a byproduct of, "It can't be done"
I didn't see mentioned in this thread the alternative (UMMM) Unattended Make My Manifest, which can be used for strictly command line builds.
Although personally I usually hand edit UMMM output, and then add the file as a custom resource named 1, with resource type "#24"
Registration-Free COM is a godsend for distribution.
I didn't see mentioned in this thread the alternative (UMMM)....
Believe that was developed after this. Usually we here don't advertise our projects on other people's codebank submissions which is why you didn't see it mentioned
Insomnia is just a byproduct of, "It can't be done"
Believe that was developed after this. Usually we here don't advertise our projects on other people's codebank submissions which is why you didn't see it mentioned
my bad! just to clarify - i definitely can't take credit for wqweto/Vlad's project since 2009.
my bad! just to clarify - i definitely can't take credit for wqweto/Vlad's project since 2009.
No, I know who developed UMMM. Just trying to make a point regarding codebank submissions. Now, in the general help portion of the forum, totally difference scenario. I may, for example, reference this project as an option to solve a particular problem. It is completely understandable and expected to see other posts that reference other projects/solutions
Insomnia is just a byproduct of, "It can't be done"
No, I know who developed UMMM. Just trying to make a point regarding codebank submissions.
Understood, I can see my comment is completely rude on a codebank post.
This project does a great job of making Manifests simple. Thanks for a great app!
I played with the idea and found a partial solution, but decided against it for one specific reason... If the OCX can render itself themed and the rest of the controls on the form are not themed, I'd think the user would not be happy. The OCX would not appear similar to other controls it is hosted with.
Please could you tell why we need to add all this (below) to the Project?
I tried without it and everything works fine, buttons and controls looks good.
Code:
Private Declare Function LoadLibraryA Lib "kernel32.dll" (ByVal lpLibFileName As String) As Long
Private Declare Function FreeLibrary Lib "kernel32.dll" (ByVal hLibModule As Long) As Long
Private Declare Function InitCommonControlsEx Lib "comctl32.dll" (iccex As InitCommonControlsExStruct) As Boolean
Private Declare Sub InitCommonControls Lib "comctl32.dll"()
Private Type InitCommonControlsExStruct
lngSize As Long
lngICC As Long
End Type
Private Sub Main()
Dim iccex As InitCommonControlsExStruct, hMod As Long
' constant descriptions: http://msdn.microsoft.com/en-us/library/bb775507%28VS.85%29.aspx
Const ICC_ANIMATE_CLASS As Long = &H80&
Const ICC_BAR_CLASSES As Long = &H4&
Const ICC_COOL_CLASSES As Long = &H400&
Const ICC_DATE_CLASSES As Long = &H100&
Const ICC_HOTKEY_CLASS As Long = &H40&
Const ICC_INTERNET_CLASSES As Long = &H800&
Const ICC_LINK_CLASS As Long = &H8000&
Const ICC_LISTVIEW_CLASSES As Long = &H1&
Const ICC_NATIVEFNTCTL_CLASS As Long = &H2000&
Const ICC_PAGESCROLLER_CLASS As Long = &H1000&
Const ICC_PROGRESS_CLASS As Long = &H20&
Const ICC_TAB_CLASSES As Long = &H8&
Const ICC_TREEVIEW_CLASSES As Long = &H2&
Const ICC_UPDOWN_CLASS As Long = &H10&
Const ICC_USEREX_CLASSES As Long = &H200&
Const ICC_STANDARD_CLASSES As Long = &H4000&
Const ICC_WIN95_CLASSES As Long = &HFF&
Const ICC_ALL_CLASSES As Long = &HFDFF& ' combination of all values above
With iccex
.lngSize = LenB(iccex)
.lngICC = ICC_STANDARD_CLASSES ' vb intrinsic controls (buttons, textbox, etc)
' if using Common Controls; add appropriate ICC_ constants for type of control you are using
' example if using CommonControls v5.0 Progress bar:
' .lngICC = ICC_STANDARD_CLASSES Or ICC_PROGRESS_CLASS
End With
On Error Resume Next ' error? InitCommonControlsEx requires IEv3 or above
hMod = LoadLibraryA("shell32.dll") ' patch to prevent XP crashes when VB usercontrols present
InitCommonControlsEx iccex
If Err Then
InitCommonControls ' try Win9x version
Err.Clear
End If
On Error GoTo 0
'... show your main form next (i.e., Form1.Show)
Form1.Show
If hMod Then FreeLibrary hMod
'** Tip 1: Avoid using VB Frames when applying XP/Vista themes
' In place of VB Frames, use pictureboxes instead.
' 'bug' may no longer apply to Win7+
'** Tip 2: Avoid using Graphical Style property of buttons, checkboxes and option buttons
' Doing so will prevent them from being themed.
End Sub
Please could you tell why we need to add all this (below) to the Project?
I tried without it and everything works fine, buttons and controls looks good.
You don't need to call InitCommonControlsEx at all, so almost all of that is pointless overhead. ActiveX containers and controls already take care of everything it might theoretically accomplish (i.e. they call it themselves).
What needs to happen for things to work and not crash is to first load shell32.dll and then load comctl32.dll (in that order) before the first VB Form or Control is loaded. While you can skip one or both steps and get away with it sometimes, in other situations your program will just fail. It seems to vary by program, controls used, Windows version, and some "secret sauce" we haven't uncovered yet.
The call to InitCommonControlsEx causes comctl32.dll to be loaded into your process' address space. Nothing else that it does matters. You can also just use the simpler InitCommonControls call and accomplish just as much. Or you could explicitly call LoadLibrary on comctl32.dll instead. Same result.
However if you didn't cause shell32.dll to load first you are still at risk of "mysterious aborts." These seem to occur less frequently than if you failed to load comctl32.dll at all before loading a Form or Control, but they still occur.
Once again, you could use LoadLibrary on it, or just call some innocuous entrypoint in the library. I like to use IsUserAnAdmin:
Code:
Private Declare Function IsUserAnAdmin Lib "shell32" () As Long
It's short and sweet, works every time. You can call it as a subroutine since you don't care about its return value. Just call it before calling InitCommonControls.
External manifests are deprecated and should not be used. But ignoring that, nothing changes.
As I already said in post #77, you don't need "all this code" anyway and just something like this is plenty:
Code:
Option Explicit
Private Declare Function InitCommonControls Lib "comctl32" () As Long
Private Declare Function IsUserAnAdmin Lib "shell32" () As Long
Private Sub InitCommonControlsVB()
'Reliably cause these libraries to be loaded in the correct order
'so that a Common Controls 6.0 manifest doesn't cause a crash.
On Error Resume Next
IsUserAnAdmin
InitCommonControls
End Sub
Private Sub Main()
InitCommonControlsVB
Form1.Show
End Sub