Not sure I have the stomach to try it out now, but it might help with the Global property. It would be nice to match VBScript Regex object member names exactly so that we have a drop-in replacement for it.
jpbro, I add zip-file with dll-maker, tlb and ready project,
just to show you (demo, not in production) that it is possible, based on manual posted by dilletante.
However, I don't think this is a good idea (for current stady of development, at least):
1) Any modifications in prototype of methods/properties or adding a new one will require editing the ODL and re-compilation of TLB (you can't just add them to class). Maybe, it is acceptable to convert project to TLB version when you completely finish it.
2) I still unable to prepare correctly this part of ODL:
After compilation and adding TLB to project, IDE said: "Bad interface for implements: method uses type that is not supported by Visual Basic"
on this line:
Code:
Implements PCRE.IPcreMatches
So, currently no support for your enumerator in the demo:
Code:
'Public Function IPcreMatches_Enumerator() As IUnknown
' Set IPcreMatches_Enumerator = mo_Matches.[_NewEnum]
'End Function
Again, repeat that I don't think addaing this feature now is a good idea, as since it greatly complicates the further coding.
Last edited by Dragokas; May 29th, 2017 at 05:52 AM.
That's really great Dragokas, thanks for putting it together! I agree that we should wait until everything is more or less complete before pursuing this further since it will require unnecessary extra work if we have to keep editing the ODL file.
As for the problem with the enumerator, I'm out of my depth here, but we can tackle it later. Thanks again
you have to derive your IUknown from stdole. Randy Birch quotet an old VB6-KB Article 194913 PRB: Visual Basic and Visual Basic for Applications Do Not Understand IUnknown** Data Type in MIDL Type Library in which the problem is explained in more detail.
Unfortunately, the forum does not allow me to send a link to Google Groups. But the message title you're looking for is Variable uses a type not supported in Visual Basic (Error 458).
When IUknown derived from stdole, it requires mktyplib.exe to be properly compiled, not MIDL. Mktyplib produces other compilation problems.
So, I successfully used another recommendation together with MIDL:
There are a few caveats when using MIDL to create vb6 typelibs.
You either have to import stdole2.tlb into your typelib (for the typical iunknown definition used by vb6)
or you have to edit the "base" idl files such as Unknwn.idl to properly change them without getting redefinition errors.
Modifying these files directly is the only way to get around the compilation issues.
Also you can keep the modified files in the same directory as your typelib - and MIDL will use those over the ones in your DDK/SDK folders. That way they only apply to the current typelib, and you can keep the DDK ones pristine / unmodified.
NOTE:
These issues were originally worked out by McKinney (Hardcore VB) the creator of Win and WinU.tlb.
Win/WinU.tlb was the first huge Win32 API Typelib for VB6 built using MIDL.
@dragokas just adding to the discussion, you've actually fixed the issue the more correct way.
Just trying to spread the knowledge.
Last edited by DEXWERX; May 30th, 2017 at 07:04 AM.
Reason: corrected import file name.
Just updated the code over at GitHub with preliminary support for a Replace method that wraps the pcre2_subsitute method.
@Dragokas & @DEXWERX & @oumba - thanks for you work on the TLB and autoconverter...I haven't had a chance to look at it in depth yet, but once I firm up the project's object model I'll give it a spin. Much obliged!
Since we decided to follow a pure Pcre2 naming model with just a little additions (like, SubMatches),
I decided to make a proxy-dll, that fully imitate VBS.Regexp object model.
Benefits of such dll: it can be added to any project that already use a LOT of lines with VBS.Regexp calls (with predominantly late binding) without needs to change anything in source code to move to Pcre. Just need to do replacings like 'set oRegexp = CreateObject... => to 'set oRegexp = new cRegexp'.
Need some help. Break my mind and don't undestand why your CPcreMatches returns _NewEnum and my cRegExpMatchCollection doesn't (the code is almost same) ?
Can you look, please => sub 'TestRegex3' - var. 'lo_Matches'. 'For each' failed.
The same in your sub 'TestRegex2' - var. 'lo_Matches2' works well.
I finished portable proxy wrapper.
Benefits:
- opportunity to switch beetween VScript.Regexp and PCRE2
- automatically switch to PCRE2 if creating instance of VScript.Regexp is failed (damaged vbscript.dll file or registration info).
- simple to integrate to a big project that is already use VBScript.Regexp, just replace a declaration and "= new" keywords.
- fully imitate VBScript.Regexp object model
- portable (1 class + 1 tlb + 1 dll) or (1 class + 1 tlb + resource-file for pcre2-16.dll, that is mean single exe)
I opened several issues in jpbro's repository. Feel free to make hints.
Also, I noticed that PCRE2 doesn't support \u sequence that is a big problem for me: http://www.regextester.com/pregsyntax.html
So, what is mean UTF-16 when we compiled pcre dll ?
Also, I noticed that PCRE2 doesn't support \u sequence that is a big problem for me: http://www.regextester.com/pregsyntax.html
So, what is mean UTF-16 when we compiled pcre dll ?
I need to use such patterns like: \u5378\u8F7D
PCRE2 *does* support \u, but by default, it assumes Perl itself handles preprocessing. If you want PCRE2 to manually handle \u, you need to set the PCRE2_ALT_BSUX options bits when compiling the regex (via pcre2_compile). See details here:
@dragokas - when using my VBPCRE2 wrapper, can you try me.Options.Compile.AlternateBsuxHandling = True and see if that works? I'll happily handle any errors over at GitHub.
PS: Please pull the latest version from GitHub because I made some fixes to the Options classes earlier.
Tanner_H, that's nice news. Thank you.
jpbro, AlternateBsuxHandling works well. Now, with \U, \u \x support. Yes
wqweto, please look now. I updated both release and .\using directory. However, "release" have only redistributable files (no demo).
1.1 Beta
Added unicode support for RichTextBox
Added missing RICHTX32.OCX and reg-free manifest
pcre2-16.dll added to resources with ID 501.
1.0 Beta
Added GUI
Added all using examples in frm-file.
Applyed all PCRE2 wrapper fixes by jpbro.
Added .PCRE2 property => for accessing directly to PCRE2 wrapper object model.
Added missing .FirstIndex property
Added Wrapper's object model tree in comments of frm-file.
Cleaned garbage in TLB and maker, hided private methods and some fixes.
Flag "Alternate Bsux Handling" (ability to use \u, \U, \x in pattern sequences) set to TRUE by default now.
jpbro, I can double the same GUI for committing to your original wrapper if you liked it.
I must said, currently ProxyWrapper fits all my needs in post # 1,
and already integrated to a project with long complex regular expression patterns without errors.
So, the topic can be considered as resolved.
____________________________
I noticed, that PCRE2 considers "$10" as replacing string a bit differently than VBScript.Regexp.
He thinks that 10 is a 10-th group. In the same time VBScript.Regexp think that it is 1-st group (see example in screenshot above: I specificially set a dot - $1.000).
How can this problem be resolved? - I want remove dot (.) here: "$1.000", but PCRE2 will think that $1000 is a 1000-th group, instead of 1-st.
In case anyone is using my VB PCRE2 wrapper out there, there have been a couple of small improvements/bug fixes in the last couple of days. The latest version is available on GitHub (MIT licensed source and binaries) here: https://github.com/jpbro/VbPcre2
Hi, Jason. Thanks for the update.
Unfortunately, I currently have no time to make new face for your ActiveX.
But I will look ASAP, as well as adding fixes to my wrapper accordingly to your recent patch.
Unfortunately, I currently have no time to make new face for your ActiveX.
But I will look ASAP, as well as adding fixes to my wrapper accordingly to your recent patch.
No worries! I know we're all volunteering time here, so I don't have any expectations of things getting done at any particular time (or even at all!)
Special thanks to Tanner Helland for pointing out that there was a new version available, and for his invaluable assistance getting the new version of PCRE2 built!
Is shipping both pcre2-16.dll and VBPCRE2.dll separately made on purpose? For instance pcre2-16.dll to be updated separately or something?
I'll take a look if pcre2-16.dll can be staticly compiled in VBPCRE2.dll -- will be much more convenient IMO.
Edit: Cannot find lib folder w/ pcre2-16.dll sources it was compiled from and/or any build scripts. Is it the stock .dll from PCRE distribution?
Btw, binary/build artefacts is more convenient to be distributed under releases tab while repo's bin folder only contains scripts and similar (.bat files, README) to facilitate library release/debug builds.
cheers,
</wqw>
Last edited by wqweto; May 17th, 2018 at 01:39 AM.
Is shipping both pcre2-16.dll and VBPCRE2.dll separately made on purpose? For instance pcre2-16.dll to be updated separately or something?
I'll take a look if pcre2-16.dll can be staticly compiled in VBPCRE2.dll -- will be much more convenient IMO.
Well not necessarily on purpose, but not really by accident either. Having them separate does let me build the 2 DLLs only as needed which has some benefits if there are only changes in one of the DLLs. Since I already having to ship an external DLL with my apps (VBPCRE2.dll), having to include a second one (pcre2-16.dll) doesn't seem much more painful to me. Actually, I already ship 20+ DLLs with my main application, so what's one more
That said, if it's possible/easy to link them together in a single build with some kind of automated process then I'm not against merging them. I just don't want to add a lot of manually steps if I don't have to.
Originally Posted by wqweto
Edit: Cannot find lib folder w/ pcre2-16.dll sources it was compiled from and/or any build scripts. Is it the stock .dll from PCRE distribution?
That said, I may have a licensing conundrum (and it may even affect whether or not we can statically link pcre2-16.dll and VBPCRe2.dll).
First, PCRE2 is BSD licensed, which doesn't seem to require me to distribute any additional source code or files used to build the binary - but I may well be wrong about this. It does seem to require that I include the license text available here, so I will make that addition to the LICENSE file ASAP.
The tricky bit is this: VBPCRE2.dll is MIT licensed - so can we statically link a BSD licensed DLL with an MIT licensed one? If so, what else are we required to provide in terms of source/files used to build and link them? TBH I'm a bit out of my depth, here, but I think I'll open an issue at GitHub to start a discussion and make sure everything is above board.
Originally Posted by wqweto
Btw, binary/build artefacts is more convenient to be distributed under releases tab while repo's bin folder only contains scripts and similar (.bat files, README) to facilitate library release/debug builds.
Thanks for the heads up about GitHub Releases...I'll take a look at what needs to be done to use this feature going forward.
i m compare efficiency between ur wrapper and jpbro's
did i use it wrong?
it seems ur wrapper is quicker in initialize,
but slower in runtime
Code:
Private Sub Form_Load()
Const n As Long = 100
Dim i As Long
Dim lng As Long
Dim c As IRegExp
Debug.Print "Dragokas wrapper:"
mTimer = 0
Set c = New cRegExp
Debug.Print "Initialize:" & vbTab & mTimer
c.UsePcre = True
c.Global = True
mTimer = 0
c.Pattern = "([a-z])\1"
For i = 1 To n
lng = c.Execute("aabbccddeeff").Count
Next i
Debug.Print "Execute:" & vbTab & mTimer
mTimer = 0
For i = 1 To n
c.Test "aabbccddeeff"
Next i
Debug.Print "Test:" & vbTab & vbTab & mTimer
mTimer = 0
For i = 1 To n
c.Replace "aabbccddeeff", "$1"
Next i
Debug.Print "Replace:" & vbTab & mTimer
Debug.Print "jpbro wrapper:"
Dim d As VBPCRE2.cPcre2
mTimer = 0
Set d = New VBPCRE2.cPcre2
Debug.Print "Initialize:" & vbTab & mTimer
d.GlobalSearch = True
d.Pattern = "([a-z])\1"
mTimer = 0
For i = 1 To n
lng = d.Execute("aabbccddeeff").Count
Next i
Debug.Print "Execute:" & vbTab & mTimer
mTimer = 0
For i = 1 To n
d.Test "aabbccddeeff"
Next i
Debug.Print "Test:" & vbTab & vbTab & mTimer
mTimer = 0
For i = 1 To n
d.Replace "aabbccddeeff", "$1"
Next i
Debug.Print "Replace:" & vbTab & mTimer
End Sub
Code:
in IDE test result:
Dragokas wrapper:
Initialize: 0.0079
Execute: 21.0799
Test: 2.0151
Replace: 1.1002
jpbro wrapper:
Initialize: 2.8076
Execute: 6.8408
Test: 1.8128
Replace: 0.8613
and while compiled:
Dragokas wrapper:
Initialize: 0.0201
Execute: 11.515
Test: 1.091
Replace: 0.2866
jpbro wrapper:
Initialize: 3.3294
Execute: 3.334
Test: 1.0692
Replace: 0.3066
i have a problem using your wrapper in office 2010 vba x86
all these lines expose an same error:
Public Function IRegExp_Replace(sourceString As String, replaceVar As Variant) As String
Public Function IRegExp_Test(sourceString As String) As Boolean
Public Function IRegExp_Execute(sourceString As String) As IRegExpMatchCollection
"The procedure declaration does not match the event description, or the procedure has the same name"
The entire code is implemented in vb6 as a multi-functional component, encapsulated into com dll. It is equivalent to a top-level vb6 developer who brings together excellent algorithms and shares them for free for everyone, which is very good.
I don't know if there is a com dll library developed with vc ++ that integrates a large number of functions, or a standard dll. That must be the fastest operating efficiency.
It's like asking vc ++ to develop a vba8.dll (com dll), or msvbvm60_advance.dll