How do you deal with Visual Basic 6.0 frm and frx files in source control?

Question

This is always a pain, no matter what source control system I have used (Visual SourceSafe, CVS, ClearCase, etc.). The binary .frx files always cause a problem when merging Visual Basic forms.

I know...I know...why are you using Visual Basic...because there are lots of legacy applications still written using it and although I hate to admit it, I actually like using it (ducks tomatoes).

Coben

Answer 1

You need to just bite the bullet and include them in version control system. Unfortunately, they do contain information that isn't available anywhere else in the source. (The bitmaps added to ImageList controls, for example.) If you lose those files, you can't rebuild the application correctly.

Unmake

The bullet is bitten. Good to know I'm not the only one! – Coben

Answer 2

Frx merges are a major pain. Which I why I recommend if your version control system allows locking, make sure you use it on the frx files to avoid merges. For example, Subversion supports locking to avoid issues with editing bitmaps and other binary files.

With that being said, my company and I have been using Subversion on a Visual Basic 6.0 CAD/CAM project for over five years and only ran into a problem with frx merging a handful of times.

In all cases, it was a simple matter to resolve. Mainly by one person making a backup of his form and resolving the problem by hand via cut and paste. If somebody is doing major work on one of the forms that has a lot of bitmaps, then we make sure we lock it and get that part of the project over as fast as possible.

P.S. Don't apologize for Visual Basic's FRX strangeness. Other packages have the same issue anytime two people edit the same bitmap, WAV or any other type of binary file that software will depend on.

Dayak

Thanks for the locking suggestion. I'm pretty sure ClearCase (version control system we use) will allow this this. – Coben

Answer 3

I work on ClearCase and stumble upon exactly the same problem, and a Google query make me end up here. As the answers here do not really provide the technical nitty-gritty on how to deal with these files on ClearCase, allow me to add what I did today to solve my problem.

Problem:

The .frx files have been created with the "compressed_files" type in ClearCase, which does not support merges, and could create conflicts that will puzzle the unaware user (and get you a support call in the CM team).

Solution:

The overall script which we will follow is described in this IBM technote

1. First thing first, you need to understand which type of handling you want for your binaries: NEVER_MERGE or COPY.

   The reference to these two new types can be found in this other IBM technote

   I personally choose the COPY type for the .frx files

   You need to create the new types using the ClearCase Type Explorer.

   I suggest you create first the new types on a test VOB somewhere. And once you are happy with your testing, create the new types in your Admin VOB. If you are working on UCM, that would be at your PVOB(s) level. In either case make sure you declare the new type as Global. If you are not working on UCM, and do not have an admin VOB, you will have to create the new types in all the individual VOBs you want to use it.

   Just follow the instructions on the above technote.

   NOTE, IMPORTANT: You will have to delete the new types from the "lower" VOB if you have created them in a test VOB before creating them in an admin VOB (assuming your test VOB was under the Admin VOB). Deleting an element type delete all the instances of this type, so do NOT create this new types for testing on real files, as deleting the types from a lower level VOB will delete all the files associated with it !

   Be careful not to lose any important data !

2. You need to make sure that any new .frx files will be created with the proper new type.

   For this, you need to change the "Magic File". It is a good idea to centralise the changes to magic files (rather than to have to change it on every individual client). You want to change it once, on a Server (e.g. your VOBs Server), and make people use an environment variable called "MAGIC_PATH" to point to it.

   See this IBM Technote

   Once you have copied and rename the default.magic file in your MAGIC_PATH location, you need to change the definition of the .frx files.

   There are actually two entries for them in the default magic file:

   (...)
   
   # Match non-printable files by name
   
   (...)
   
   vb_form_compiled vb_derived compressed_file : !-printable & -name "*.[fF][rR][xX]" ;
   
   (...)
   
   # assumed to be binary
   
   (...)
   
   vb_form_compiled vb_derived compressed_file : -name "*.[fF][rR][xX]" ;
   

   I commented them both and added the following line before the last entry in the magic file:

   # New COPY type:
   
   frx_visual_basic vb_derived COPY : -name "*.[fF][rR][xX]" ;
   
   # catch-all, if nothing else matches
   compressed_file : -name "*" ;
   
   #EOF
   

   Every client which defines the MAGIC_PATH environment variable should now pick that properly, so any new files created with .frx suffix will have the "COPY" element type.

3. If you already have .frx files in your VOB, you want to change them to the new type:
   • Lock the VOB
   • use the following command on Windows from the DOS prompt (from the top of your VOB):

     cleartool find . -all -name "*.frx" -exec "cleartool chtype COPY %CLEARCASE_XPN%"
     

     This will change the element type for all *.frx files to the new COPY type

   • Unlock the VOB

     You need to do that for all your VOBs.

Note: The first tech note at the top of this answer states that "This type of merge (i.e. COPY) is not supported by the Rational ClearCase Remote Client." as of ClearCase 7.0.1 and from the test I did today, this is now supported.

Coonhound