search

github-linguist / linguist

Language Savant. If your repository's language is being reported incorrectly, send us a pull request!
MIT License
12.3k stars 4.26k forks source link

Visual Basic 6.0 or VB6 #5824

Closed Gagniuc closed 1 year ago

Gagniuc commented 2 years ago

Language name

Visual Basic 6.0

URL of example repository

https://github.com/Gagniuc/Markov-Chains-Simulation-framework https://github.com/Gagniuc/Markov-Chains-Prediction-framework https://github.com/Gagniuc/Discrete-Probability-Detector-in-VB6 https://github.com/Gagniuc/Micro-chart-in-VB https://github.com/Gagniuc/Visual-Sequence-Alignment-in-VB6 https://github.com/Gagniuc/Simple-sequence-alignment-in-VB6 https://github.com/Gagniuc/Markov-Chains-The-weather https://github.com/Gagniuc/Markov-Chains-detector-in-VB6 https://github.com/Gagniuc/Genomin https://github.com/Gagniuc/Mapping-pixels-to-LEDs-for-the-Photon-pixel-coupling-method https://github.com/Gagniuc/WebCam-software-sampling https://github.com/Gagniuc/VB6-add-GUI-objects-at-runtime https://github.com/Gagniuc/Motif-detection-VB6 https://github.com/Gagniuc/PI-laboratory-in-VB6 https://github.com/Gagniuc/PromKappa-3.0-Objective-Digital-Stains-in-VB6

URL of syntax highlighting grammar

https://github.com/Gagniuc/Micro-chart-in-VB However, an extra color for the inbuilt functions will be extraordinary.

Most popular extensions

Notice that the .vbp and .vbw extensions are VB6 specific.

The extensions commonly used by this language:

Detected language

VBA

lildude commented 2 years ago

I have no experience in either language, but from what I've read this is going to be a challenge to implement if you plan to have all those extensions supported by both languages as I believe they have similar (identical?) syntax, which means how would one differentiate programmatically between a VB6 .cls file and a VBA .cls file? The same thing would apply to all the other shared extensions.

It would be easier to implement VB6 with just the .vbp and .vbw extensions if they really are unique to the language as there would be no need to differentiate them from another language.

It's probably also worth pointing out the current classification came about because of https://github.com/github/linguist/pull/4725 which pulled things out from under the "Visual Basic" name into different names. /cc @zspitz as the author of that PR.

That PR was based of previous discussions in https://github.com/github/linguist/issues/2418

zspitz commented 2 years ago

I would say the primary difference on the code level between VBA and VB6 is the different global objects available to them. But that is also true of VBA when running under different host environments -- the global objects available when VBA is running under Microsoft Word are different from those available when running under Microsoft Excel.

Gagniuc commented 2 years ago

I have no experience in either language, but from what I've read this is going to be a challenge to implement if you plan to have all those extensions supported by both languages as I believe they have similar (identical?) syntax, which means how would one differentiate programmatically between a VB6 .cls file and a VBA .cls file? The same thing would apply to all the other shared extensions.

It would be easier to implement VB6 with just the .vbp and .vbw extensions if they really are unique to the language as there would be no need to differentiate them from another language.

It's probably also worth pointing out the current classification came about because of #4725 which pulled things out from under the "Visual Basic" name into different names. /cc @zspitz as the author of that PR.

That PR was based of previous discussions in #2418

The .vbp and .vbw extensions are unique to the VB6 language. Thus, if any VBA files are accompanied by files with .vbp and .vbw extensions, than all repository is Visual Basic 6.0. Just look on any of my repositories on VB6.

lildude commented 2 years ago

The .vbp and .vbw extensions are unique to the VB6 language. Thus, if any VBA files are accompanied by files with .vbp and .vbw extensions, than all repository is Visual Basic 6.0. Just look on any of my repositories on VB6.

Linguist looks at files in isolation and doesn't consider any other file in the repo during analysis as it identifies the breakdown of all languages within a repo, not the overall repo language. When you see a repo identified as a particular language, it's only because that's the predominant language by bytes of code within the repo.

Gagniuc commented 2 years ago

So basically the extension and size of file is all that the Linguist takes into consideration? I am confused ...

lildude commented 2 years ago

No, it also takes into account some of the content of each file, if it needs to. This is where things like the modeline, shebang, heuristics and classifier come into it. However, there's an ordering in the strategies used which is detailed in the docs at https://github.com/github/linguist/blob/master/docs/how-linguist-works.md. Essentially, it's a funnel into which a lot of languages go with each strategy attempting to whittle the list down to one language. This is done on a per-file basis.

The file size isn't considered at all... the bytes of code within the file are what are considered, but then only to determine the percentage breakdown of the languages already identified.

Gagniuc commented 2 years ago

Nonetheless, it will be nice to have a version of the Linguist that correctly detect VB6 projects.

DecimalTurn commented 2 years ago

Here's an idea: We add VB6 as a new language with the following two extensions: * .vbp * .vbw (EDIT: No longer adding these extensions, see next message for explanations.)

Once VB6 is part of Linguist, it should be possible for VB6 project maintainers to overrides the language definition by adding the following lines to their .gitattributes file : 

*.bas linguist-language=Visual-Basic-6.0
*.cls linguist-language=Visual-Basic-6.0
*.frm linguist-language=Visual-Basic-6.0

▶More about overrides

DecimalTurn commented 2 years ago

I've managed to run the Linguist project on my machine using WSL, so I should be able to make a PR for this issue shortly, but looking more closely at the documentation for VB6, I've found a much larger list of files that would be part of a VB6 project: Project File Formats.

Among theses file types, if we exclude the extensions already associated to VBA, I've found that only the following extensions actually use the VB6 syntax:

The other ones are binaries or follow another syntax which tells me that we should exclude them from being recognized as VB6 by Linguist.

For instance, .vbp files are Visual Basic Project files and they contain the project configurations, but that doesn't mean that they should be identified as VB6. They are actually much closer to an INI file than to VB6 code1. For comparison, .vbproj files are VB.NET project files and they are identified as XML instead of VB.NET (as they should be).

For those reasons, I'm going to use .ctl and .dsr for the extensions exclusively associated to VB6 in the PR I'll submit.

[1] A .vbp file is essentially a collection of key-value pairs, just like an INI file, but .vbp files don't support comments apparently (source) and even if they do support tags (source), it's undocumented, so I wouldn't go as far as to say that a .vbp file can be identifed as INI.

DecimalTurn commented 2 years ago

Now that the PR was merged, this issue can be closed. However, it will still take some time before the change goes live on GitHub:

Note: New languages will not appear in GitHub's search results for some time after the pull request has been merged and the new Linguist release deployed to GitHub.com. This is because GitHub's search uses go-enry for language detection but tends to lag behind Linguist by a few weeks to months. This in turn requires an update to the underlying search code once go-enry is inline with Linguist. source

Gagniuc commented 2 years ago

Now that the PR was merged, this issue can be closed. However, it will still take some time before the change goes live on GitHub:

Note: New languages will not appear in GitHub's search results for some time after the pull request has been merged and the new Linguist release deployed to GitHub.com. This is because GitHub's search uses go-enry for language detection but tends to lag behind Linguist by a few weeks to months. This in turn requires an update to the underlying search code once go-enry is inline with Linguist. source

Thank you very much. Now VB6 can be recognized. I look forward to see Visual Basic 6.0 on some of my projects. The VB6 community will much appreciate this !

ElroySullivan commented 2 years ago

WOW, I'd just like to second the effort to have VB6 recognized as a separate language. It certainly isn't VBA, even though it has many similarities. There continues to be a quite active VB6 community which should be given its due respect. Sincerely, Elroy Sullivan, PhD.

Gagniuc commented 2 years ago

WOW, I'd just like to second the effort to have VB6 recognized as a separate language. It certainly isn't VBA, even though it has many similarities. There continues to be a quite active VB6 community which should be given its due respect. Sincerely, Elroy Sullivan, PhD.

Indeed! Thank you Dr. Sullivan !

Gagniuc commented 2 years ago

I've managed to run the Linguist project on my machine using WSL, so I should be able to make a PR for this issue shortly, but looking more closely at the documentation for VB6, I've found a much larger list of files that would be part of a VB6 project: Project File Formats.

Among theses file types, if we exclude the extensions already associated to VBA, I've found that only the following extensions actually use the VB6 syntax:

  • .ctl (User Control file)
  • .dsr (Active Designer file)

The other ones are binaries or follow another syntax which tells me that we should exclude them from being recognized as VB6 by Linguist.

For instance, .vbp files are Visual Basic Project files and they contain the project configurations, but that doesn't mean that they should be identified as VB6. They are actually much closer to an INI file than to VB6 code1. For comparison, .vbproj files are VB.NET project files and they are identified as XML instead of VB.NET (as they should be).

For those reasons, I'm going to use .ctl and .dsr for the extensions exclusively associated to VB6 in the PR I'll submit.

[1] A .vbp file is essentially a collection of key-value pairs, just like an INI file, but .vbp files don't support comments apparently (source) and even if they do support tags (source), it's undocumented, so I wouldn't go as far as to say that a .vbp file can be identifed as INI.

Does the new modification make an association between ".vbp" and Visual Basic 6.0, or ".vbw" and Visual Basic 6.0? If it doesn't, can you please make this possible? Because if you look at my own Visual Basic 6.0 projects, there are no ".ctl" or ".dsr" files at all. But all the Visual Basic 6.0 projects that I have seen so far have something in common: files with the extension ".vbp" and ".vbw". More than likely for this reason we do not see any change.

fafalone commented 2 years ago

VBP/VBW files are related to VB6, but they do not use the VB6 language. You wouldn't mark them as code because they're not code.

Once .ctl/.dsr is added as a language actually called vb6, you'll be able to, I hope, manually mark repos as VB6 by overriding the language of .bas/.frm/etc with a .gitattributes like *.bas linguist-language=vb6

Asking for a feature that sees .vbp files and does that automatically is I think asking too much for a language Microsoft (which owns GitHub now) wants dead.

Gagniuc commented 2 years ago

VBP/VBW files are related to VB6, but they do not use the VB6 language. You wouldn't mark them as code because they're not code.

Once .ctl/.dsr is added as a language actually called vb6, you'll be able to, I hope, manually mark repos as VB6 by overriding the language of .bas/.frm/etc with a .gitattributes like *.bas linguist-language=vb6

Asking for a feature that sees .vbp files and does that automatically is I think asking too much for a language Microsoft (which owns GitHub now) wants dead.

In an earlier talk here, @lildude pointed out that the linguist detects the extensions of the files, and not the content. Thus, the ".vbp" and ".vbw" are the only signatures that can be detected for Visual Basic 6.0. This is why I insist so much on the two extensions.

fafalone commented 2 years ago

Right but it only applies the syntax highlighting to that file, and the syntax highlighting rules VB6 needs don't match vbp, there's no functionality to say 'Because this file has extension x, override default on extension y'

.ctl and .dsr are extensions that are only associated with VB6 and not VBA, and are actually VB6 language files. Therefore it makes the most sense to add them as a language and allow manual overrides, rather than hope for a major functionality addition from a Microsoft-owned company exclusively to support a language it's trying to kill.

I suppose you could do it with VBP/VBW instead but it's improper to define the wrong syntax highlighting for something. Since they're unlikely to add the auto-override, it shouldn't matter that most VB6 projects don't have user controls or are addins.

Gagniuc commented 2 years ago

I understand the issue now. The problem with .ctl/.dsr is that they are not present in the majority of the VB6 projects. At this point in time maybe it is better to have the identification of VB6 projects even if the syntax highlighting does not "compute" yet.

lildude commented 2 years ago

At this point in time maybe it is better to have the identification of VB6 projects even if the syntax highlighting does not "compute" yet.

Most definitely not. Syntax highlighting is the primary motivator for adding support for a language for most contributors. Knowningly and deliberately getting this wrong would defeat that purpose and people will be very vocal about it when they notice it's wrong. This will result in them opening issues here, only for us to redirect them to the grammar maintainer who will rightly point out the files aren't written in the language the grammar is written for.

The approach taken is the best compromise. If you are happy for the wrong syntax highlighting, then you can make that change with an override without it affecting everyone else.

The next best approach would be to add a heuristic that can be used to differentiate between the languages of a shared extension.

If you can come up with a regular expression that can be used to correctly and reliably differentiate the content of the VB6 files from the VBA or other similar languages that share the same extension, please feel free to open a PR adding this to the heuristics.

Until then, the only option is a manual override once the next release of Linguist has been deployed to GitHub (planned for mid Nov after GitHub Universe).

Gagniuc commented 2 years ago

The only way to properly distinguish between Visual Basic 6.0 and VBA is to consider the ".vbp" and ".vbw" extensions. The syntax highlighting on the other files (.bas, .frm and so on) can remain as in VBA because it is BASIC after all.

lildude commented 2 years ago

The only way to properly distinguish between Visual Basic 6.0 and VBA is to consider the ".vbp" and ".vbw" extensions.

Indeed, but we'd need to somehow identify the language of the content to differentiate the languages who share the same extension. This is where the heuristic comes in. In short: codify how you would identify the language of the file with either extension if you were presented it in isolation. (Linguist looks at files in isolation).

I know nothing about VB6 and VBA but from what I've read, the languages are almost identical so a heuristic is going to be very challenging to come up with, but we'd certainly accept a PR that succeeds in doing this.

XusinboyBekchanov commented 2 years ago

There is one more difference in VB6 in the second line of frm files is the text Begin VB.Form. VB6:

VERSION 5.00
Begin VB.Form Form1 
   Caption         =   "Form1"
   ClientHeight    =   3015
   ClientLeft      =   120
   ClientTop       =   465
   ClientWidth     =   4560
   LinkTopic       =   "Form1"
   ScaleHeight     =   3015
   ScaleWidth      =   4560
   StartUpPosition =   3  'Windows Default
   Begin VB.TextBox Text1 
      Height          =   375
      Left            =   720
      TabIndex        =   2
      Text            =   "Text1"
      Top             =   360
      Width           =   3375
   End
   Begin VB.CommandButton Command2 
      Caption         =   "Command2"
      Height          =   735
      Left            =   840
      TabIndex        =   1
      Top             =   1680
      Width           =   2895
   End
   Begin VB.CommandButton Command1 
      Caption         =   "Command1"
      Height          =   615
      Left            =   1320
      TabIndex        =   0
      Top             =   960
      Width           =   2295
   End
End
Attribute VB_Name = "Form1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False

VBA:

VERSION 5.00
Begin {C62A69F0-16DC-11CE-9E98-00AA00574A4F} UserForm1 
   Caption         =   "UserForm1"
   ClientHeight    =   3165
   ClientLeft      =   45
   ClientTop       =   390
   ClientWidth     =   4710
   OleObjectBlob   =   "UserForm1.frx":0000
   StartUpPosition =   1  'CenterOwner
End
Attribute VB_Name = "UserForm1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
Private Sub UserForm_Click()

End Sub
XusinboyBekchanov commented 2 years ago

The .cls file is also different. VB6:

VERSION 1.0 CLASS
BEGIN
  MultiUse = -1  'True
  Persistable = 0  'NotPersistable
  DataBindingBehavior = 0  'vbNone
  DataSourceBehavior  = 0  'vbNone
  MTSTransactionMode  = 0  'NotAnMTSObject
END
Attribute VB_Name = "Class1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = True
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = False

VBA:

VERSION 1.0 CLASS
BEGIN
  MultiUse = -1  'True
END
Attribute VB_Name = "Class1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = False
fafalone commented 2 years ago

That is true... you could reliably distinguish by that.

But, that's still a new feature, isn't it? Linguist doesn't go by the actual code, just the extension.

This comes up with twinBASIC, a very advanced project to create a true successor to VB6. The language is 100% compatible with VB6/VBA6 and VBA7 (minus GoSub which isn't implemented yet), yet even when I haven't added any of the new syntax/keywords it supports, just an untouched VB6 import, it doesn't detect .twin files as VBA, I have to add a .gitattributes specifying that's the syntax highlighting that should be applied. (If anyone hasn't followed the news on this, the project is incredibly far along, just needs some more work on the GUI and controls support, which have basic support but not complete support, but can already compile large, complex projects and has many new features, like 64bit exes, generics, bitshift operators, new assignment operators, in-language interface definitions, AddressOf on class members, multithreading support (via API for now), and native mode support (can create kernel mode drivers).

So anyway, you could distinguish them independently of extension-- for .cls and .frm at least-- but does that feature even exist?

lildude commented 2 years ago

But, that's still a new feature, isn't it? Linguist doesn't go by the actual code, just the extension.

Nope. Linguist looks at some of the content via the heuristics (ie regular expressions) and tokenisation by the classifier but only after at least 2 languages have been identified by the extension.

Both classification methods require identifiable differences in order to detect the languages involved.

The language is 100% compatible with VB6/VBA6 and VBA7 (minus GoSub which isn't implemented yet), yet even when I haven't added any of the new syntax/keywords it supports, just an untouched VB6 import, it doesn't detect .twin files as VBA, I have to add a .gitattributes specifying that's the syntax highlighting that should be applied.

This will be because Linguist doesn't know anything about that extension so ignores the file.

So anyway, you could distinguish them independently of extension-- for .cls and .frm at least-- but does that feature even exist?

Yup. See above.

This whole VB-family of languages classification issue sounds like it's going to be a lot like the .h extension used by the C-family of languages which was a long battle until we finally resolved on the strategy in use and detailed in the troublshooting doc. If a similar approach can be found for these VB languages sand their shared extensions, then that would be great. If not, the only option is manual overrides.

XusinboyBekchanov commented 2 years ago

TwinBasic also differs from VB6 and VBA in terms of the keywords: Module ... End Module Class ... End Class. There is also a major difference: These are the file extensions - .twin

lildude commented 2 years ago

Sounds like TwinBasic could have it's own language entry, if it meets the documented popularity requirements and is the only user of the .twin extension.

XusinboyBekchanov commented 2 years ago

Sounds like TwinBasic could have it's own language entry, if it meets the documented popularity requirements and is the only user of the .twin extension.

And where to read about the "documented popularity requirements"?

lildude commented 2 years ago

The very first sentence of the "Adding a language" section of the CONTRIBUTING.md file.

fafalone commented 2 years ago

Not that popular yet (:user/:repo would allow multiple repos from the same user to count? That would be closer.), but it's still pre-release and I don't think most people know how far along it is... so many years of empty promises and projects abandoned early. And I don't know what the deal is with RadBasic... honestly looks suspect at this point. Zero updates nearly a year, but still offering paid early access, which must have an NDA attached because nobody is saying a thing about it. Which is odd considering how impressive it looked for the early stage it was in for last update. And some of the things the developer has said don't inspire confidence.

But anyway, since the heuristic feature exists I can only assume there's resistance to implementing it? It's not like we discovered the differences in this 20 year old language yesterday, or that this issue hasn't been posted about for years.

Although I don't think it's possible to distinguish .bas, except in the case you could semi-reliably distinguish VBA7 if it used new features. Perhaps bas could default to VB6 unless it detects PtrSafe or LongLong?

DecimalTurn commented 2 years ago

But anyway, since the heuristic feature exists I can only assume there's resistance to implementing it? It's not like we discovered the differences in this 20 year old language yesterday, or that this issue hasn't been posted about for years.

@fafalone, I don't think there is actual resistance, it's just that nobody has taken the time to contribute to the Linguist project to implement those heuristics yet.

As you mentioned and to add to the discussion, VBA has 2 data/variable types and one keyword that VB6 doesn't have. Those were introduced with Microsoft Office 2010 for 64-bit support:

Source: Microsoft Learn

The issue is that a lot of files might not contain those new types or keyword even when running on a 64-bit application, but that's better than nothing.

DecimalTurn commented 2 years ago

The .cls file is also different. VB6:

VERSION 1.0 CLASS
BEGIN
  MultiUse = -1  'True
  Persistable = 0  'NotPersistable
  DataBindingBehavior = 0  'vbNone
  DataSourceBehavior  = 0  'vbNone
  MTSTransactionMode  = 0  'NotAnMTSObject
END
Attribute VB_Name = "Class1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = True
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = False

VBA:

VERSION 1.0 CLASS
BEGIN
  MultiUse = -1  'True
END
Attribute VB_Name = "Class1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = False

@XusinboyBekchanov, so what you are saying is that those lines would not be valid inside a VBA .cls file, is that correct?

Persistable = 0 'NotPersistable DataBindingBehavior = 0 'vbNone DataSourceBehavior = 0 'vbNone MTSTransactionMode = 0 'NotAnMTSObject

XusinboyBekchanov commented 2 years ago

But anyway, since the heuristic feature exists I can only assume there's resistance to implementing it? It's not like we discovered the differences in this 20 year old language yesterday, or that this issue hasn't been posted about for years.

@fafalone, I don't think there is actual resistance, it's just that nobody has taken the time to contribute to the Linguist project to implement those heuristics yet.

As you mentioned and to add to the discussion, VBA has 2 data/variable types and one keyword that VB6 doesn't have. Those were introduced with Microsoft Office 2010 for 64-bit support:

  • LongPtr. VBA now includes the variable type alias LongPtr. The actual data type that LongPtr resolves to depends on the version of Office that it is running in; LongPtr resolves to Long in 32-bit versions of Office, and LongPtr resolves to LongLong in 64-bit versions of Office. Use LongPtr for pointers and handles.
  • LongLong. The LongLong data type is a signed 64-bit integer that is only available on 64-bit versions of Office. Use LongLong for 64-bit integrals. Conversion functions must be used to explicitly assign LongLong (including LongPtr on 64-bit platforms) to smaller integral types. Implicit conversions of LongLong to smaller integrals are not allowed.
  • PtrSafe. The PtrSafe keyword asserts that a Declare statement is safe to run in 64-bit versions of Office.

Source: Microsoft Learn

The issue is that a lot of files might not contain those new types or keyword even when running on a 64-bit application, but that's better than nothing.

There are also some differences (bas files can be distinguished in this way): VB: Clipboard, App, Screen, Printer, ... and etc. VBA: Excel, Word, ActiveDocument, ... and etc.

XusinboyBekchanov commented 2 years ago

The .cls file is also different. VB6:

VERSION 1.0 CLASS
BEGIN
  MultiUse = -1  'True
  Persistable = 0  'NotPersistable
  DataBindingBehavior = 0  'vbNone
  DataSourceBehavior  = 0  'vbNone
  MTSTransactionMode  = 0  'NotAnMTSObject
END
Attribute VB_Name = "Class1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = True
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = False

VBA:

VERSION 1.0 CLASS
BEGIN
  MultiUse = -1  'True
END
Attribute VB_Name = "Class1"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = False

@XusinboyBekchanov, so what you are saying is that those lines would not be valid inside a VBA .cls file, is that correct?

Persistable = 0 'NotPersistable DataBindingBehavior = 0 'vbNone DataSourceBehavior = 0 'vbNone MTSTransactionMode = 0 'NotAnMTSObject

I don't know it's valid or not, but by default the VBA IDE generates code like this. And there is no option in the IDE to change this (and it's invisible inside the IDE. Can only be seen through Export File).

fafalone commented 2 years ago

There are also some differences (bas files can be distinguished in this way): VB: Clipboard, App, Screen, Printer, ... and etc. VBA: Excel, Word, ActiveDocument, ... and etc.

You can use VB6 for Office automation, so those will appear in it sometimes.

The others are pretty generic words, so while there's no builtin object, it's probably not uncommon to encounter those strings, so would have to be careful with exactly what you're looking for.

VBA will strip out the VB6 .cls properties, so even if you imported a class with them you don't have to worry about them appearing.

XusinboyBekchanov commented 2 years ago

There are also some differences (bas files can be distinguished in this way): VB: Clipboard, App, Screen, Printer, ... and etc. VBA: Excel, Word, ActiveDocument, ... and etc.

You can use VB6 for Office automation, so those will appear in it sometimes.

The others are pretty generic words, so while there's no builtin object, it's probably not uncommon to encounter those strings, so would have to be careful with exactly what you're looking for.

VBA will strip out the VB6 .cls properties, so even if you imported a class with them you don't have to worry about them appearing.

If the keywords are generic, then the language should be defined as VBA. If there is Clipboard, App, Screen, Printer, Persistable, DataBindingBehavior, DataSourceBehavior, MTSTransactionMode, VB.Form and etc then it should be defined as VB6.

fafalone commented 2 years ago

I'm saying Clipboard, App, Screen, and Printer are common generic words, so some care needs to be taken to look for them only in language-specific implementations; look for Clipboard.SetText, App.Title, Screen.TwipsPerPixelX, etc. as those would be uncommon outside of VB6, since substitutes for them are less likely to implement the same syntax (although some might, for code portability reasons... have a Clipboard class module you can drop into VBA so your clipboard-using code has the same syntax as VB6).

DecimalTurn commented 1 year ago

@Gagniuc, with the new release, you might see the change if you push changes to one of your repos.

Gagniuc commented 1 year ago

@Gagniuc, with the new release, you might see the change if you push changes to one of your repos.

If you look at any of the VB6 projects on my account, all of them say VBA, as before.

DecimalTurn commented 1 year ago

If you look at any of the VB6 projects on my account, all of them say VBA, as before.

You need to push a change on the repo to trigger a new analysis by Linguist.

Gagniuc commented 1 year ago

If you look at any of the VB6 projects on my account, all of them say VBA, as before.

You need to push a change on the repo to trigger a new analysis by Linguist.

Indeed it works

Absolutely wonderful. The Visual Basic community appreciates what you did very much :) Thank you!

thetrik commented 1 year ago

Thank you!

lildude commented 1 year ago

Support has shipped. Closing.