>This isn't really a CI issue. It's a build/version control issue. It's called Feature Hiding. I like option 5, but go the opposite. Make them visible and have the compiler option disable them.

Hi Craig

Thanks for the input. I'm hiding bits of the feature to permit other code to be integrated to the main branch. I took your idea to a point and have the compiler directive remove the controls for now, and it will not remove them in future. I suppose a single header file could drive many such feature bits.

Branching/Merging would be the better way to go, then the controls would not even be added to the form, and all my changes would be merged in at the correct time. The compiler directive could remove the controls, and eventually would not remove them. They clutter up the source a bit, but not enough to worry about.

>
>
>>Hi all
>>
>>The scenario is there's a team of programmers. I am working on many changes across the app. As part of my changes, the customer form needs a textbox and label added. I added these in the form designer. I've kept all of the changes checked out. However, now another team member needs to make a change to the customer form. I want to be able to check in my change, but add a switch of some kind to prevent the textbox and label from being added, as opposed to removing them at runtime. Can you help me prepare a list of available options?
>>
>>1 - Programmatically add the controls - position them etc. within a condition.
>>2 - visually add the controls - return .F. from the init if a high-level public-like private variable is defined.
>>3 - Compiler directives - but how do they apply to visually added controls?
>>4 - I guess I'm spoiled by genscrnx and genmenux where we could add a condition that would prevent code being generated.
>>5 Make the controls visible = .f. in the form designer and add compiler directive wrapped code to make them visible = .t.?
>>Can compiler directives check for the existence of a file - I'd rather keep the test out of the file system - in RAM.
>>6 - make a new object with properties that drive conditional integrations - have this object instantiated before a build exe. All features that are intended to be delivered would be included in the exe. All that are to be excluded would be. At design time, developers instantiate this object and by flipping properties, are able to see before and after.
>>
>>Any other ideas?