- (Major) Apparently there is no way to instantiate /virtual classes; a descendant class must be written using C++. This means that you cannot effectively use any component (or other class), such as ListView, which returns data using virtual classes, without writing C++ code. Update: there is an INHERITS keyword which makes it sound like you actually can write a child class in Gambas; see inheritance for ongoing documentation. (This may have been fixed in v3; need to check.)
- (Major but livable) Hovering over variables at runtime does not display their current value, as in VB, nor does there seem to be any other way of inspecting values at runtime other than inserting debug code to display values.
- (Major but livable) Help is not context-sensitive
- (Annoying; bad for writing good code) Constants cannot be defined using other constants (e.g. A = "something" & B, where A and B are both constants)
- (Puzzling) The error "Not enough arguments (#4)":
- can appear at the point where a call to a subroutine has a problem inside the called subroutine, rather than at the point highlighted. (Use "RETURN" within the called subroutine to isolate the problem line, as Gambas will not let you step inside a subroutine when this problem happens.)
- can be a sign of a property being called as a function
- (Minor) SHIFT-TAB does not reliably unindent (seems to work better when multiple rows are highlighted)
- (Minor) Although the syntax for accessing field data is nominally similar to VB's syntax, a variant which works under VB does not work in Gambas:
with objData intID = !ID strName = !Name end with
intID = objData!ID strName = objData!Name
- (Minor) Identifiers are not automatically capitalized to match their declaration, as in VB; fortunately, identifiers are not case-sensitive for compilation, so this doesn't make things ugly the way it does in C/C++. (The pop-up list of methods/properties/events sometimes won't show up, however, unless the object's name is properly capitalized.)
- The field-list popup isn't smart in certain circumstances:
- Type me.controlname.field (use a real control name and a real field name)
- Move cursor somewhere else
- go back to same line, and highlight the "." between "controlname" and "field"
- type "."
- (minor) The list doesn't automatically select the field which was there already
- (annoying) When you select the field you want, it is inserted between "." and the fieldname that was there before. This follows logically from the editing rules, but is not what we want to happen; the selected fieldname should replace the old fieldname.
Fixed in 3.x
- (Major, may be a problem for debugging) No "view stack" window (This is fixed in v3.)
- (Major but livable) There is no equivalent to the VB right-click "Go to definition" menu command (v3 has "Find definition (F2)")