Results 1 to 8 of 8
  1. #1
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Run time error 60061 (Word 2000)

    I am (mistakenly) repeating a programmed Import of all VBA source modules from a folder.
    The first pass works fine.
    The second (my mistake) pass imports the BAS modules, appending each name with a digit "1", but baulks when it arrives at a duplicate UserForm (FRM module).
    It's my fault, and i should learn not to click a comand button twice when in a hurry (grin), but:

    For the life of me I can't find a reason why appending a digit "1" to the userform module wouldn't work as well as it does for a plain code module (BAS).
    There appears to be nothing especial in the FRM or FRX (attached) that a simple name-fix wouldn't, well, fix.
    <pre>.VBComponents.Import(strFileName) ' fails if duplicate form</pre>


  2. #2
    Plutonium Lounger
    Join Date
    Mar 2002
    Posts
    84,353
    Thanks
    0
    Thanked 29 Times in 29 Posts

    Re: Run time error 60061 (Word 2000)

    The .frm file is a plain text file that can be viewed with Notepad or any other text editor. If you do so, you'll see that it contains a reference to the .frx file. This causes the problem - the internal reference has not been updated, obviously.

  3. #3
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Run time error 60061 (Word 2000)

    > it contains a reference to the .frx file
    Right!
    I still can't see a logical reason for not doing with frm/frx what gets done with BAS.
    If you/I can see the file reference we can automate it.
    Could automate it.
    Could have automated it had we been employed by a large software company.

    It's no big deal, just that at times like these I question my sanity.

  4. #4
    WS Lounge VIP rory's Avatar
    Join Date
    Dec 2000
    Location
    Burwash, East Sussex, United Kingdom
    Posts
    6,280
    Thanks
    3
    Thanked 191 Times in 177 Posts

    Re: Run time error 60061 (Word 2000)

    What would be the point? Any code that uses the userform needs to refer to it by name, so would be broken if it got renamed. <img src=/S/shrug.gif border=0 alt=shrug width=39 height=15>
    Regards,
    Rory

    Microsoft MVP - Excel

  5. #5
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Run time error 60061 (Word 2000)

    > Any code that uses the userform needs to refer to it by name,
    I know what you are saying, and that part is true.
    remember too that on this one I goofed and re-ran my importer without purging modules.
    However (grin), Since You Ask <font color=ff8c00>(tm)</font color=ff8c00>:

    I have occasions when I want to employ two or more similar forms in an application. I craft one, get it working with all the bells & whistles, then want to export it, and immediately import it one or more times to institute clones within the application.
    VBE does it for code modules and VBE does it for class modules, and it is a useful technique. But VBE does it not for forms.

    We know that one would have to change the name, and hence the referral, but I can't see any logical reason not to.
    After all, I can clone a class modules and yes, I probably will change the name from "StringStack1.cls" to "ModuleStack.cls" or "ProjectStack.cls" or "FileStack.cls" as I go. But at least I can quickly make clones.
    The same applies for userforms - there appears to be no logical obstruction to bringing in clones of userforms, automatically upgrading the file names and module names by appending a digit "1", "2" etc. as is already done for class modules and code modules, and then requiring the user to make real names changes to make use of them.

    Right now I can (1) export a user form (2) edit the name of the current form by appending a digit and (3) importing the originally-named form. It achieves the same end and is, I suppose, the same amount of work from my end, but has an annoying inconsistency with other two module types.

    I've gone on too long. My original post was more a scratch-my-head post. I've been cloning modules for years. The more I get into automating the process the more I see the inconsitencies.

  6. #6
    WS Lounge VIP rory's Avatar
    Join Date
    Dec 2000
    Location
    Burwash, East Sussex, United Kingdom
    Posts
    6,280
    Thanks
    3
    Thanked 191 Times in 177 Posts

    Re: Run time error 60061 (Word 2000)

    <hr>has an annoying inconsistency with other two module types<hr>
    ah, but a userform is not just a module. It is different from a class module and thus behaves differently. I agree though that there does not appear to be any reason why the import could not have been programmed, but it is possibly better practice to create your userform template, name it as a template (e.g. frmInputTemplate) and then export it. Any form within your project should be given a real name so thereafter importing a new template will not be an issue, aside from the fact you can't import 4 at once and then start work on them; but that's probably not a bad thing.
    As it happens, if you copy the .frm file and change the relevant names in it but leave the reference to the .frx file as it is, the import will still work so it is fairly easy to program round - a batch file could do it (and I know how you like those! <img src=/S/grin.gif border=0 alt=grin width=15 height=15>)
    Regards,
    Rory

    Microsoft MVP - Excel

  7. #7
    Platinum Lounger
    Join Date
    Feb 2001
    Location
    Yilgarn region of Toronto, Ontario
    Posts
    5,453
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Run time error 60061 (Word 2000)

    > you can't import 4 at once and then start work on them;

    Ah, but you can if you are writing VBA code to build applications programmatically.

    It is, I suspect, the old thing that "We never anticipated that users would do that!"
    I can program around it.
    But it's a pain when I don't have to program around it for the others.
    For the record, the application is a library generator that receives a template which has (recorded within its variables) a list of folders. The generator's job is to import source modules from each folder.
    Think of one folder holding a set of BAS that are general-purpose VBA procedures, that can be used as utilities in any VBA application. Another folder holds Excel-specific VBA, another PPT-specific, and so on. It's not uncommon/impossible to have similar named modules (Utils.BAS is a good example) arriving from different folders. Appending a digit makes for a clean compile.

    The userforms screw it up. I quite agree that code that references "frmPrince" will go a tad awry when it references "frmPrince" recently known as "frmPrince1".

    I just wish the import was consistent enough to rename everything.

  8. #8
    WS Lounge VIP rory's Avatar
    Join Date
    Dec 2000
    Location
    Burwash, East Sussex, United Kingdom
    Posts
    6,280
    Thanks
    3
    Thanked 191 Times in 177 Posts

    Re: Run time error 60061 (Word 2000)

    But if you are building apps programmatically, you are stuffed anyway since you have to know which routines reference the userform, know what the userform was renamed to, and then re-write the routines; which was my original point - you shouldn't want to do this anyway!
    Regards,
    Rory

    Microsoft MVP - Excel

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •