VB6 global module state

VB6 desktop applications were single-user processes, and global state was cheap: a Public gUserLevel As Integer in a module is visible to every form and class. Forms add more state. Referencing frmSummary.txtTotal anywhere silently loads the default instance of frmSummary, running its Form_Load, and invisible text boxes on forms are routinely used as variables to pass values between screens. Business rules read these globals and hidden controls, so a premium calculation can depend on which branch the user picked on a login screen an hour ago. Moving that logic to a multi-user web service without making the state explicit causes the worst kind of defect: one user's branch, discount authority or running counter leaks into another user's request.

The VB6 parser builds a symbol table across all modules, forms and classes in the .vbp project, including the controls declared in .frm files. Every Public and Global module variable, every Static local, and every control property used as data storage is a state cell. Dataflow analysis records which procedures write each cell and which read it, and the call graph gives the event order that can lead from a write to a read. Implicit form loads are detected wherever a form's members are referenced without an explicit instance. Rules extracted from procedures that read global state get those cells listed as inputs.

Per-user values such as branch and authority level become fields of a request or session context passed explicitly to services, typically from the authenticated identity. Shared reference data such as rate tables becomes an injected, read-only service with its own cache policy. Counters and sequence numbers move to the database. Hidden controls disappear: whatever they carried becomes a property of a request or a resource.