Hello Europe: MMM 0.7 is Here

There won't be a version 0.6.8 as suggested earlier. For whatever reasons several people seem to want another version numbering scheme to be used, one that exposes the build number. So now we're at MMM 0.7!

New Version 0.7

I wasn't quite ready to put out a new MMM version but then over the past three days I got two bug reports I couldn't ignore.

Both of these involved a problem with "comma as decimal point" in some international locales. A very strange coincidence, but right after fixing this the first time a second report of the same problem came in. This was enough to get me to pull a new release from the MMM codebase now that I have changed it to use the current decimal point character.

Along with the first report a second issue was raised. Some people actually do compile into folders other than the Project folder it seems. So MMM will follow the Path32 key in the .VBP file now instead of simply requiring that the compiled EXE be located in the Project folder. And yes, this appears to be the same issue raised in a comment to an earlier blog post here... that I sort of blew off because I thought MMM was already handling the matter. Doh!

The bigger changes I have coming along for MMM are not ready for beta release yet. So only a few additional changes are present in this MMM 0.7 version. These should not matter much to most users, but details can be found in the readme.txt file in this package.

ZIP Archive, Not EXE

This version has been posted as a simple ZIP archive instead of a self-extracting EXE. The tools for extracting from a ZIP are extremely common and even Windows has been capable of doing it alone for some time now. Some people are running MMM on Win9x systems (??) and the self-extractor I was using requires NT crypto libraries, so it could be a problem for these guys.

On the plus side the download is only about half the size as before: MMM 0.7

As always, let me know about any problems. Be sure to keep MMM version 0.6.7 or earlier around in case of problems with the new one.

Posted at Saturday, August 15, 2009 12:56 PM
In General Category | Permalink

Comments
#4 ~ 24 (Total 24)

Could you zip and email just your VB6 project's .VBP file? This might offer another clue.

The emai link should be up there under the picture (a sailboat right now) as "contact me."

Posted by BVOCS on Friday, September 4, 2009 10:28 PM

I did notice I had a reference to some chartwiz control and removed and it got past the first runtime error but when I tried to finish it I got another runtime error. Same error invalid property value

Posted by Gary Simonelli on Tuesday, September 8, 2009 12:40 PM

Thanks Gary, I got your additional info. A screen capture of the MMM window at the time of failure mgiht help too. I'm also sending you an interim build with two bug fixes to try.

Posted by BVOCS on Wednesday, September 9, 2009 08:38 PM

I'm having another problem with an MMM generated manifest. It seems like version independent ProgIDs are skipped altogether. I'm referencing COMCTL32.OCX and only COMCTL.ImageListCtrl.1 is registered, the version-independent COMCTL.ImageListCtrl is missing.

I think you have to nest a <progid> inside <comClass> in case a coclass has both progids. Obviously VB6 generated classes can't have this kind of indirection but VC ones always do.

Btw, this time I'm posting with my real e-mail address in case you have a test build for me :-)

Posted by wqweto on Monday, September 28, 2009 04:24 AM

That's a good point. I will take a look at this and see what I can do about it. Are you saying you are using CreateObject() to obtain COMCTL32.OCX controls? When you use "Set X = New Y" I don't think the ProgIDs are ever used.

Posted by BVOCS on Monday, September 28, 2009 09:46 AM

Actually it's Controls.Add but yes, I do need version independent ProgIDs. I can hard code it as COMCTL.ImageListCtrl.1 but wanted to share the quirk.

I'm having troubles with licensed controls (including COMCTL32) and had to add manual Licenses.Add "{ProgID}", "{uncovered_license_string}" for every "late-bound" added control.

Finally, I'm working on Unattended MMM (UMMM) which is turning out as a very nice rip-off of the manifest creating feature of MMM :-)) It's fairly complete now, just want to implement it in our daily build before releasing to public. Will keep you posted.

Posted by wqweto on Monday, September 28, 2009 10:29 AM

Btw, another bug report. You are populating miscStatusIcon as per KB828629. The article instructs to populate miscStatus attribute which is misleading. VB6 registered classes always populate CLSID\{control_cls_id}\MiscStatus\1 key which corresponds to miscStatusContent attrubute. Also, the default value under MiscStatus key is 0 which means that the default status should be set to miscStatus=""

miscStatusIcon's value comes from MiscStatus\4 key. I had troubles (flickering, disappearing) with controls that had only miscStatusIcon as MMM generates now. Providing miscStatusContent for these solved the issues.

I'm using MSDN's Assembly Manifests article (http://msdn.microsoft.com/en-us/library/aa374219(VS.85).aspx) to figure out which is which in the manifest files. Having a 400k LOC VB6 project for manifest testing helps too :-))

Posted by wqweto on Monday, September 28, 2009 10:47 AM

I'm finally done with the portable build of our product and so here is the first public release of the UMMM tool:

http://sourceforge.net/projects/ummm

Many thanks for the (more than) great inspiration MMM has been!

Posted by wqweto on Tuesday, September 29, 2009 10:25 AM

Much food for thought here. I already see what MMM is doing incorrectly with those control DVASPECT attributes. It is more complicated than you suggest, since even VB6 controls can have more than just the Content and other controls might have all four! However Content might be the only one relevant here.

Congratulations on UMMM. It should meet a common need that I haven't gotten around to addressing in MMM yet.

I think you always have to manually add to the Licenses collection when using late-bound licensed controls. The compiler will never have enough info to handle this automatically.

Early versions of MMM used to include multiple ProgIds. I took that logic out since nobody seemed to be using it. Returning it should be easy enough.

Posted by BVOCS on Friday, October 2, 2009 03:13 PM

I have working some time for deploying a product with Registry-Free COM. I feel MMM the best tool for generating Native COM manifest information.

Posted by Yanhua on Thursday, October 15, 2009 01:48 AM

I have working some time for deploying a product with Registry-Free COM. I feel MMM the best tool for generating Native COM manifest information.

Posted by Yanhua on Thursday, October 15, 2009 01:49 AM

I just attempted to use MMM 0.7 to scan a large VBP file (referencing 25 projects DLLs, OCXs). It throws the following error, what should I be doing next?
---------------------------
MMM
---------------------------
Run-time error '380':

Invalid property value
---------------------------
OK
---------------------------

Posted by Saurabh on Friday, November 13, 2009 10:49 AM

This is probably the same bug or limitation others have reported in the past. If somebody could send me a whole Project that reproduces the problem I might make some headway with it.

I'd like to think anyone running into this could create a smaller stripped-down example instead of having to send me something they'd rather not share. I suspect it may be related to certain 3rd party controls though, such as some of those from vbAccelerator.

Posted by BVOCS on Sunday, November 15, 2009 06:32 AM

The MMM 0.7 app scans the large VBP file just fine if I exclude all OCX files (editing the INI file). I'm still trying to understand why its throwing an error when OCX files are included. Any insights? Most of these OCXs are custom components. Not sure if I can share all the details, but this VBP (exe) references a lot of DLLs and OCXs that are themselves VBPs. If I explicitly exclude OCX as dependencies then the programs scans VBP just fine and creates the manifest.

Posted by Saurabh on Monday, November 16, 2009 03:53 PM

This has been a very helpful tool for us, many thanks! We are having one small problem ... the following line in the vbp file generates an error something like "... a serious problem was encountered while processing your project's dependencies ..." (it is not critical since the type library is used as a reference only). We simply make a copy and delete the line and all is well.

Reference=*\G{11269241-F241-11CF-BD9A-00AA00575603}#1.0#0#Code\SHELLLNK.TLB#VB 5 - IShellLinkA Interface(ANSI)

Posted by Mark Ustik on Tuesday, November 17, 2009 04:58 PM

here is a similar command line tool:
http://www.codeproject.com/KB/COM/regsvr42.aspx

and a similar gui tool (on the tools tab):
http://tzitech.webs.com/

works from W98 to W7

Posted by nano on Monday, December 7, 2009 09:26 AM

Cannot download the GUI version of tool mentioned. The link on the associated website is bad

Posted by Saurabh on Wednesday, January 6, 2010 10:38 AM

I'm sorry, I know nothing about that tool and it isn't associated with MMM. Perhaps you can contact nano above at the link provided in his name?

Posted by BVOCS on Friday, January 8, 2010 05:14 PM

Great tool!

How do you open an .mmmp file?
They get produced, but I can't figure out how to re-open!

/Johan

Posted by Johan St�ck on Monday, February 22, 2010 03:25 AM

> How do you open an .mmmp file?
> They get produced, but I can't figure out how to re-open!

Sadly that part hasn't been completed. It was always intended but never high enough on the list to get done yet. Soon though I hope.

Posted by BVOCS on Thursday, February 25, 2010 07:35 PM

<< View previous comments