VB-Project restrictions 1. All files of source VB-Project must be in one folder, projectfolder. The target, myproject.vbp file, must be in this folder, not in subfolders. It is not recommended to break this rule because of following consequences: 1. myproject.vbp file can reference forms, classes, modules outside of projectfolder, but siblings to projectfolder. 2. If myproject.vbp references files two levels out ot its parent, the file is parsed, but result is not saved on disk. For example: for tree ..\BigParent\projectfolder\myproject.vbp for text in myproject.vbp: Form=..\SiblingOne\SubOfSibling\myform.frm - will work result will be palced in ..\BigParent\RESULT_FILES\projectfolder\SiblingOne\SubOfSibling\myform.frm ..\BigParent\RESULT_FILES\projectfolder\SiblingOne\SubOfSibling\myform.frm.inc Form=..\i_am_a_sibling.FRM - will work result will be palced in ..\BigParent\RESULT_FILES\i_am_a_sibling.FRM Form=..\..\i_am_too_far.FRM - nothing will be saved 2. If present, option explicit must be first statement in declaration section. 3. CommandButtons Leaf menu nodes must have some code in click events. No events will be linked to Menu Container node events in dll. 4. Locked text boxes are not indicated on Browser: user can change the text, but *-* this changes have no effect. 5. Control arays must be consequent. For example: if mnuHelp.count = 11 then Compi will not handle correctly control mnuHelp(120). 6. No comments allowed starting with ' in project file *.vbp. Limitations First, which programmer should know that vb2asp (at time of this writing) is not a complete converter. The principal things which not converted in full: - VB-interactive-logic (if Msgbox then ... modalness ... and alike ... ), - VB-interruptable statements ( End and alike ), - .Visibility property and .Show method, - Form Control's properties, - Form Control's events, - Dynamic GUI control load. - one-directional flow of some properties: from Dll to Browser. Modalness is not converted in full. Modal forms and MsgBox interrupt code and may wait for user to respond. However, if code interrupted, the code cannot respond to a Browser. Thus, user cannot to respond back to the Server. This question is about application logic. Probably the best solution, it to take care about modal forms before conversion: split the code which calls modal contruscts to code-before-call and after-call. When loading modul forms, try hide other forms, and when user responds show other forms back. CommonDialog is not converted at all. What vb2asb does for MsgBox is written here: MsgBox 1. The line MsgBox [name | string] is replaced with web_1 [name | string ] This is only the case when MsgBox 'converted'. However, this changes fucntionality because web_1 does not wait on a server for user response, 'it waits' on Browser. What web_X does may be found in web_msg_mod.Bas file. 2. In other cases, programmer may want to eliminate poping up MsbBoxes on server manually. Visibility Statements form1.visibility = True form1.show vbModeless display form1 modeleslly. This is forbiden by dll-syntax and actually in VB6. (Actually, VB4 still allows modeless behaviour by setting '.visibility = True'.) Programmer should take care about non-converted .visibility and .show statements manually. In general, .Visibility and .Show property and method are not converted. If programmer sets ConvertShow switch, then this cases will be converted, but programmers approval is still required. VB-interruptable statements ( End and alike ) End statement 1. Statement 'End' is replaced with web_End only if it is at the beginning of the line. 'If a then End' won't be converted. Fortunately, VB Compiler will forbid End statments in Dll; thus, find all of non-converted. 2. In cases when End is is replaced with web_End, this changes functionality of the Application: web_End does not interrupt the code. The programmer may has to think about unwanted code which may run after web_End. All form-controls converted patially only. For example, even CommandButton is labeled 'converted', the font property of it is not converted. Map-files should be checked to see which properties are transfered from dll to browser: pget_map.txt, pset_map.txt. No resorce files *.frx parser. This is a limitation of 'Preparsed' startup, but not of 'Dynamic'. What Controls are converted Form Control's events converted paritally only. For example, on change events in text box in Browser are not handled by Dll. What Events are converted After running converter, check event_map.txt for what is handled. One-directional flow of some properties: from Dll to Browser. z-layering of forms is dynamic, but 'one directional' which means that application can change z-order which reflects on browser; user can change z-order in browser which change is not submitted back to application; Vb controls z-layering is not dynamic. All controls (except menu) HTML tags are hard coded in HTML part of code. No dynamic changes in GUI control arrays They cannot be reflected on Browser. No additional controls (in controls array) on form can be (un)loaded at run-time. All required number of controls, must be created before conversion. (However, if form which practicing control's load is not the form which is displayed on Browser, there is no restriction.) Number of controls on the form can be dynamically changed only for VB Menu control. This change enabled due asp-code which dynamically creates HTML buttons as an equivalent for VB-menu.