Another three bugs are fixed in this version. The SetPrinterByName needed maintenance because of the always growing need of memory with newer versions of Windows. The command failed with some printers that returned a lot of information in the GetPrinter() API. GFA-BASIC did not reserve enough memory and caused a buffer overrun. The EOF() function now also works with inline files, the ones that are stored in the :Files section of the program. The ListView.GetFirstVisible property now returns a ListItem.
About Version-numbering
The update gets FileVersion 2.34.1803 and still belongs to GFA-BASIC product version 2.3. The Build number now shows the year and month of the release. This is the first update with the new version structure. The DllVersion$ is 2.34 Build 1803 and indicates a release date of March 2018. A DLLVERSION structure always uses a 3 part format, major, minor and build. The VERSIONINFO resource on the other hand uses 4 part format. The GfaWin23.Ocx VERSIONINFO structure == 2.34.1803.0 and leaves the last part unused. This is the version showed in the File Properties dialog:
The ocx extension indicates a DLL with OCX-controls that are described using a type library. In contrast with the purpose of the extension, the OCX controls are not publically registered and are only available within in GFA-BASIC 32.
Automation
All OLE classes defined in the GfaWin23.ocx are private to the GFA-BASIC 32 application, each OLE class is implemented with its own command. This leaves no room for dynamically loading of other COM classes and automatic use of their interfaces (like VB). Third party COM classes can only be used when they implement a dual interface so they are accessible through a dispatch identifier. In GFA-BASIC these dual interface classes are supported through the use of CreateObject and the Object.property syntax. Unfortunately, calling an interface member (property/method) requires a two step process. First the caller must ask the server for an ID number and then use that number to actually invoke the member (property/method). Each dot operator requires this two step process and accessing dual interface members can cost quite some time when a command consists of many dots. For instance something like this: Object.List.Items(n).Text requires 6 calls to the COM-class provider. GFA-BASIC 32 provides a hidden optimization for automation objects created with CreateObject(). It caches all IDs in a hash-table the first time they are used. The next time a property/method is used it is looked up in the hash-table which is considerably faster.
1104/5000
ReplyDeleteHello,
The lines () property is missing from RichEdit, the one that would match the Lines () ToString from RichTextBox to VB.
Currently I use a GfaBasic function that I developed to be able to extract the text of a precise line.
Is it possible that you anticipate this improvement?
Have a nice day, Regards.
For info my function is:
Function GetTextFromLine(ByRef MyOcx As Object, LineIndex As Long) As String
Static Long Start, L
Static Boolean IsLocked
Static String R
IsLocked = MyOcx.Locked
MyOcx.Locked = True
If LineIndex = 0
If MyOcx.LineCount > 1
R = Left(MyOcx.Text, MyOcx.CharFromLine(LineIndex + 1) - 1)
Else
R = MyOcx.Text
EndIf
Else If LineIndex < MyOcx.LineCount - 1
Start = MyOcx.CharFromLine(LineIndex) + LineIndex + 1
R = Mid(MyOcx.Text, Start, MyOcx.CharFromLine(LineIndex + 1) + Succ(LineIndex) - Start - 1)
Else If LineIndex = MyOcx.LineCount - 1
R = Mid(MyOcx.Text, MyOcx.CharFromLine(LineIndex) + LineIndex + 1)
Else
R = ""
EndIf
MyOcx.Locked = IsLocked
Return R
EndFunc
Hi Scalion, the Lines property you are referring to is part of the RichTextBox class of .NET, it is not provided in classical VB (6). Adding such a property is not worth the tremendous effort (for several reasons). Luckily, GB32 supports an even simpler way of obtaining all lines of a textbox control, the Array $() = $ command. It is used as follows and requires only one line of code:
ReplyDeleteDim text$() : Array text$() = ed1.Text
Hope this helps