Is there a way to prevent the VB6 compiler from sh

For reasons unknown, the VB6 compiler often likes to reorder the contents of .vbp files and the control descriptor block at the top of .frm files (The code that describes the properties of controls on the form. Code that you don't see in the IDE but you do see in a text editor and when doing diffs against the previous revision in version control.). This is monumentally annoying and very distracting when comparing revisions of a file.

Is there a way to prevent this?

回答1:

I don't think there's much you can do about this. I've noticed the same problem: the IDE likes to rearrange things for seemingly no apparent reason. Some things I've noticed:

When you use the SSTab control, VB likes to rearrange properties for tabs, especially the TabEnabled property.
For project files, it randomly rearranges the order in which files appear and I think I remember seeing cases where similar file types are not always grouped together and end up mixed in with the project properties. You don't have much control over this, unless you run all your VBP's through some type of sanitizer that groups like files together (forms in one group, modules in another group, etc.) and sorts them alphabetically or something, so that they remain consistent. One possible way to handle this could be to write an IDE add-on that automatically does this everytime you save changes to a project file, or come up with some batch process that will just recurse over your source directories and clean up all the VBP's in one go.
The IDE seems to randomly change the case of things; this seems to happen frequently to project references. Sometimes they are output in lower case, and other times they are output in upper case. You can get around this by choosing "Ignore Case" when you diff files in SourceSafe.
Control coordinates, such Top, Left, Height, and Width, can differ between two revisions of the same form. This is due to different developers using different screen resolutions and/or different screen DPI settings while working on the same form. If you aren't doing this already, I highly recommend that you get everyone to develop using the same resolution and same DPI setting. The differing values are caused by rounding errors that occur when logical screen coordinates at different resolutions/DPI settings are converted to twips, the default coordinate space that VB uses for laying out forms. Additionally, while I'm on the topic, make sure everyone has their display set to 96dpi, because if you develop VB forms at 120dpi, there is a really really good chance they won't display correctly on a display set to 96dpi.
There are probably other things I can't remember right now...

As for the order of controls being changed in form files, this is normal, and you usually don't want to try rearrange the order of controls by hand if it happens to change from one revision of the form to the next. The order that the controls appear in a form file determines their Z-order on the form. If the order of the controls changes in the .frm file, this will change their relative Z-order on the form, which could lead to unintended results in how your forms are displayed.

回答2:

Can you make the .vbp file read-only when you aren't editing it (ie, adding modules, etc)?

As far as form files...I can't think of any good way at all to make VB not reorder them. But I have to say that I've never encountered this before. Are you sure that something else isn't going on?

It's entirely possible that I just never paid any attention to this in the past, so I'm not saying you are mistaken, just offering my own observations.

回答3:

I have noticed that re-opening the form and saving again often restores a consistent order.