Prev: Graphical Hit Counter
Next: Picture Color Replace API
From: Tony Toews [MVP] on 20 Mar 2010 16:20
"Nobody" <nobody(a)nobody.com> wrote:

>A good similar
>alternative to VB6 is KBasic, but the IDE is poor. It takes more effort to
>make GUI apps because of this, but the syntax is 100% compatible with VB6,
>and it's multiplatform.
>
>http://www.kbasic.com/

Hold on a sec. The syntax is 100% compatible?

Does this mean you could work on a VB6 program using the VB6 IDE and
then make an exe with KBasic which wouldn't depend on the VB6 runtime
being available?

Does it support user controls as I have a number in my VB6 app. Of
course I could just download it and try. <smile>

One or two of my potential users have stated that the IT department
have removed the VB6 runtime from the users OS for "security" reasons.
If the above would work then I can take care of those folks.

Also this would work for Windows 8 if MS decides to not ship the VB6
runtime with it. I wouldn't then have to worry about distributing
the VB6 runtime.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
From: Nobody on 20 Mar 2010 18:10
"Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in message
news:25baq5hqrfjuo9n4r0jsf9f5ppq54r3l72(a)4ax.com...
> "Nobody" <nobody(a)nobody.com> wrote:
>
>>A good similar
>>alternative to VB6 is KBasic, but the IDE is poor. It takes more effort to
>>make GUI apps because of this, but the syntax is 100% compatible with VB6,
>>and it's multiplatform.
>>
>>http://www.kbasic.com/
>
> Hold on a sec. The syntax is 100% compatible?
>
> Does this mean you could work on a VB6 program using the VB6 IDE and
> then make an exe with KBasic which wouldn't depend on the VB6 runtime
> being available?
>
> Does it support user controls as I have a number in my VB6 app. Of
> course I could just download it and try. <smile>

Me too, I could just install it and find out. But what I know is that the
GUI aspect is not compatible. If your tool was command line only without
forms, then it should be easy to convert. If it has GUI, then it needs more
work.

> One or two of my potential users have stated that the IT department
> have removed the VB6 runtime from the users OS for "security" reasons.
> If the above would work then I can take care of those folks.

They usually remove VBScript, or as sometimes called "Windows Scripting
Host". VB6 runtimes are different, and disabling VBScript doesn't affect VB6
apps. However, some VB6 developers have used the scripting host, typically
by adding a reference to "Scripting.FileSystemObject", so their apps won't
work if the scripting host was disabled.

It's difficult to remove VB6 runtime files because they are protected system
files, and some manual modification to a file used by System Restore to
include or exclude files must be edited to allow them to be deleted, so this
is not a simple policy setting.

Ask that user if they really meant VB6 runtime or Windows Scripting Host.

> Also this would work for Windows 8 if MS decides to not ship the VB6
> runtime with it. I wouldn't then have to worry about distributing
> the VB6 runtime.

If they don't ship it, you can use COM SxS so no installation of the runtime
is required. You would need to include a manifest in the EXE, and put the 6
VB6 runtime files in the same folder as the EXE.

If you want to keep using VB6 for a while, and make changes in such a way
that you want to easily port to KBasic, then what I suggest is follow the
advice: Isolate GUI code from non-GUI code, or as some call it, isolate the
presentation from the implementation.

For example, assume you have a window with various controls, and some
controls depend on the value of other controls. Rather than saving some
control information into variables, then check these variables, check the
contents of the control rather than the variable. For example, lets say you
have a dropdown list with a list of colors: Black, White, Red, Custom. If
Custom was selected, a TextBox is enabled to enter color value in Hex. One
way to code it is as follows:

' Before

Option Explicit

Private ColorType As Long

Private Sub cmbColorType_Click()
ColorType = cmbColorType.ListIndex

If ColorType = 3 Then ' Custom
txtColor.Enabled = Ture
Else
txtColor.Enabled = Ture
End If
End Sub

Private Sub btnOK_Click()
Dim lColor As Long

Select Case ColorType
Case 0: lColor = RGB(0, 0, 0)
Case 1: lColor = RGB(255, 255, 255)
Case 2: lColor = RGB(255, 0, 0)
Case 3: lColor = Val("&H" & txtColor.Text)
End Select
End Sub


' After


Option Explicit

Private Sub cmbColorType_Click()
If cmbColorType.ListIndex = 3 Then ' Custom
txtColor.Enabled = Ture
Else
txtColor.Enabled = Ture
End If
End Sub

Private Sub btnOK_Click()
Dim lColor As Long

Select Case cmbColorType.ListIndex
Case 0: lColor = RGB(0, 0, 0)
Case 1: lColor = RGB(255, 255, 255)
Case 2: lColor = RGB(255, 0, 0)
Case 3: lColor = Val("&H" & txtColor.Text)
End Select
End Sub


What you notice is there are less module level variables now. So as much as
possible, in GUI events, check other controls "live", not a recording on a
module or global variable. When you follow this; virtually most of GUI
events contain GUI or simple validation code such as IsNumeric, and any
logic should be in functions that return values, especially if that logic is
more than few lines. This makes it easier to isolate GUI code from the logic
used by the program, and discard the GUI or change it significantly without
having to rewrite the rest of the code.

Example 2: Assume you have a TextBox with a full path, and you want to split
it into a path and a file name, and whether or not it's UNC path. Here is
the "Before" version:

' Before

Option Explicit

Dim IsUNC As Boolean
Dim sPath As String
Dim sFileName As String

Private Sub txtFullPath_Validate(Cancel As Boolean)
Dim i As Long

If Not IsFileExist(txtFullPath.Text) Then
Cancel = True
Exit Sub
End If

i = InStrRev(txtFullPath.Text, "\")
If i <> 0 Then
' "\" found
sPath = Left(txtFullPath.Text, i)
sFileName = Mid(txtFullPath.Text, i + 1)
End If
If Left(txtFullPath.Text, 2) = "\\" Then
IsUNC = True
Else
IsUNC = False
End If
End Sub

Private Sub btnOK_Click()
SaveSetting App.Title, "Config", "Path", sPath
SaveSetting App.Title, "Config", "FileName", sFileName
SaveSetting App.Title, "Config", "IsUNC", CStr(IsUNC)
End Sub



' After

Option Explicit

Private Sub txtFullPath_Validate(Cancel As Boolean)
If Not IsFileExist(txtFullPath.Text) Then
Cancel = True
Exit Sub
End If
End Sub

Private Sub btnOK_Click()
Dim IsUNC As Boolean
Dim sPath As String
Dim sFileName As String
Dim i As Long

i = InStrRev(txtFullPath.Text, "\")
If i <> 0 Then
' "\" found
sPath = Left(txtFullPath.Text, i)
sFileName = Mid(txtFullPath.Text, i + 1)
End If
If Left(txtFullPath.Text, 2) = "\\" Then
IsUNC = True
Else
IsUNC = False
End If

SaveSetting App.Title, "Config", "Path", sPath
SaveSetting App.Title, "Config", "FileName", sFileName
SaveSetting App.Title, "Config", "IsUNC", CStr(IsUNC)
End Sub

What you notice here is elimination of module level variables so the code is
less of a "spaghetti", and there is no need to look for these variables in
several routines to see what they may have been set to, because there aren't
any. GUI controls are already module level, so there is no need to add more.
Local variables in the same routine are fine, because you don't have to
check other routines like module level or global variables.



 | 
Pages: 1
Prev: Graphical Hit Counter
Next: Picture Color Replace API