Is there a way to prevent the VB6 compiler from shuffling the contents of files?

For unknown reasons, the VB6 compiler often prefers to reorder the contents of .vbp files and the element descriptor block at the top of .frm files (code that describes the properties of controls in the form. Code, see in the IDE, but you see it in a text editor and when compared to the previous version in version control.). This is monumental and annoying when comparing file versions.

Is there any way to prevent this?

+4
vb6
source share
3 answers

I do not think you can do this. I noticed the same problem: the IDE likes to rearrange things apparently for no apparent reason. Some things I noticed:

  • When you use the SSTab control, VB likes to reorder properties for a tab, especially the TabEnabled property.

  • For project files, it randomly arranges the order in which files appear, and I think that I remember cases where similar types of files are not always grouped and end up mixed with project properties. You do not have much control over this if you do not start your entire VBP through some kind of disinfectant that combines the files (files 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-in that automatically does this every time you save the changes to the project file or comes up with a batch process that will simply overwrite the source directories and clear all VBPs at once.

  • The IDE seems to accidentally change the case of things; this seems to happen to often design links. Sometimes they are output in the lower case, and in other cases they are output in upper case. You can get around this by choosing “Ignore Case” when you change files in SourceSafe.

  • Control coordinates such as Top, Left, Height and Width can vary between two revisions of the same shape. This is for different developers using different screen resolutions and / or different DPI settings for the screen when working in the same form. If you are not already doing this, I highly recommend that you each develop using the same resolution and the same DPI settings. Different values ​​are caused by rounding errors that occur when the logical screen coordinates with different resolutions / DPI settings are converted to twips, by default the coordinate space that VB uses for laying out forms. Also, while I'm on course, everyone has their own display set to 96 dpi, because if you are designing VB forms at 120dpi, there are really really good chances that they will not display correctly on the display set to 96 dpi

  • There are probably other things that I cannot remember right now ...

As for the order of controls changing in the form files, this is normal, and you usually don’t want to try to rearrange the order of the controls manually if this changes from one revision of the form to another. The order that the controls appear in the form file determines their Z-order in the form. If the order of the controls changes in the .frm file, this will change their relative Z-order in the form, which can lead to unexpected results in the way your forms are displayed.

+6
source share

Can you make a .vbp file read-only when you don’t edit it (that is, add modules, etc.)?

As for form files ... I can't think of anything good to prevent VB from reordering them. But I have to say that I have never come across this before. Are you sure something else is not happening?

It is possible that I have never paid attention to this in the past, so I am not saying that you are mistaken simply by suggesting my own observations.

+1
source share

I noticed that reopening the form and saving again often restore a consistent order.

0
source share

All Articles