Scope

Where HexIDE stops.

Most projects publish what they can do. This page is the other half, because a limit you find out about on day three is a bug report and a limit you read about on day one is a design decision.

Two kinds of limit follow. The first are permanent — they are what HexIDE is, and no amount of work will move them. The second are simply not built yet.

Permanent

By design, and not changing.

These are deliberate. They are the reason the rest of the project stays small enough to be finished.

The interpreter is a demonstrator: It exists so you can paste some VB6 in and watch it run — enough to kick the tyres on the workbench. It is not a migration path, and making it one is explicitly not the plan. Every divergence you hit is a mapped boundary, not a missing feature.
There is no native compiler: HexIDE does not and will not emit machine code. On Windows, if you have VB6 installed, it can drive the real compiler for you — that is a bridge to the genuine article, not a reimplementation of it.
No whole-program analysis: The language tooling works at the syntactic level. Cross-file name binding, type inference, semantic rename, find-all-references and refactoring all require a bound semantic model, and building one is a compiler front end. That belongs to a real language engine, and there is a clean, replaceable seam here for one.
Classic dialects only: The interpreter targets the language as Microsoft shipped it. Extended syntax from newer BASIC dialects is out of scope, permanently — when the interpreter meets something it does not recognise, the right answer is to fail clearly rather than to guess.
Some of VB6 is not coming back: SDI mode, User Documents, DHTML and IIS applications, the Data Environment, the Package & Deployment Wizard, and COM add-in hosting are all deliberately out of scope.

Not yet

Real gaps, actively moving.

These are genuine omissions rather than decisions, and the list goes out of date in the project's favour. If something here matters to you, it is a good thing to open an issue about.

ActiveX and OCX hosting: Third-party controls cannot be loaded. This excludes a great many real-world VB6 projects, and it is the single largest gap.
File I/O: Open, Print #, Input # and friends are not implemented in the interpreter.
Declare statements: Declare … Lib is not supported, so a module that calls into the Windows API will not load.
Conditional compilation: #If is not supported — a module containing it will not load at all, rather than one branch being taken.
Assorted intrinsics: The $-suffixed twins (Left$), type-hint suffixes (x%), IIf, Choose, Switch, RGB, Shell, Environ, DoEvents, Erase, the Mid statement and Static locals.
Built-in objects: App, Screen, Printer, Clipboard and Collection.
The Immediate window does not evaluate: Debug.Print output arrives, but you cannot type an expression into it and get an answer.
Faithful saving: Reading is solid; writing back is not. It has its own section below, because it is the most important limit on this page — what a save actually changes.

The debugger is further along than this list implies: breakpoints, Break and Continue and the current-statement highlight all work today, and the Stop statement breaks into the debugger as it does in VB6. Single-stepping, a Locals window and an evaluating Immediate pane are what is next.

Saving

What a save actually changes.

Reading a VB6 project was always the easy half. Writing one back is why HexIDE is alpha, and the gap is measured rather than estimated — against the twenty-two designer files in VB6's own Template tree. Microsoft wrote those, so any difference between what goes in and what comes out is a defect by definition, with nothing to argue about.

Sixteen of the twenty-two now survive a save byte-for-byte. The other six are not damaged by a save — they are the six HexIDE declines to save at all. What follows is what is left, listed here rather than discovered by you.

A form HexIDE cannot reproduce will not save: Six of the twenty-two carry binary data in a property HexIDE does not model — a button's picture, a list's ItemData. Writing them back would drop it, so they open read-only and File → Save declines instead of putting a lossy copy over your original. You can still open, read and run them, and Save As will write a copy somewhere else and leave the file alone.
The project file comes back tidied, not identical: A .vbp is rewritten with Type=Exe recapitalised to Type=EXE and the quotes dropped from Startup="Sub Main". It is the one file still regenerated rather than round-tripped. Whether VB6 minds the missing quotes has not been put to the compiler yet, which is exactly why it is on this list.
Twenty-two files is not every file: The measure above is Microsoft's own templates. A real project of any age carries controls, properties and header lines those files never had. HexIDE preserves what it does not understand rather than dropping it — but preserved is not the same as tested, and that gap is the honest reason to keep a backup.

One rule sits behind all three: a save that cannot reproduce a file does not attempt it. Refusing is recoverable; a silently rewritten project that only fails the next time you open it in VB6 is not. The number above is not a claim — it is a gate that runs on every build against the same twenty-two files, and it can only be lowered by fixing something.

Language tooling

What the editor actually knows.

Everything here is syntactic. That is the boundary above, stated as a feature list.

Works today: Syntax errors as you type, document structure in the two VB6 combos, quick info and signature help, folding, formatting, and keyword and declared-name completion.
Works, but lexically: Rename and go-to-definition operate within a single file and match text rather than meaning. Fine day to day; not the same thing as a semantic model.
Not there, by design: Anything needing to understand your whole project at once — cross-file references, type-aware completion after a dot, semantic diagnostics.

Why publish this

A map is more useful than a promise.

The interpreter's behaviour is checked against the real 1998 compiler rather than against anybody's memory of it — including, repeatedly, against assumptions that turned out to be wrong. That process produces two things: a runtime that behaves correctly where it works, and an exact record of where it doesn't.

Publishing the second one costs nothing and saves you an afternoon.