RNBW wrote:UEZI just wanted to show a different approach (PCRE) for the same "challenge" and that's the reason why I used same GUI and some functions from WinGUI.bi.I know it is very hard to learn regular expression but it can a mighty tool to have a simpler solution especially with string manipulation.

Counting lines with includes at the top makes not really sense as they are not visible.

My comments were not meant as a criticism. As I said it's good to see alternatives, but I found some of the code a bit difficult to follow. Also, I appreciate that the library I was using was a simplified version, but it's easy to understand and so I coded in that first. When I've got the extended version working properly (Numeric Entry Into A grid Of textboxes), I'll try some of the other libraries. The thing I liked about my code (which was an amalgamation of other people's code) is that it is short and can be used in another program without having too large an overhead.

Thank you again for your code. I've saved it and may come back to it again in the future.

jj2007 wrote:Actually, I wanted to post the Exe as Base91 code in the code box, so I tried to make the exe as small as possible using FileOptimizer, but I chose MediaFire. I cannot tell you why there are numerous calls to VirtualQuery and VirtualProtect in the code!

It seems that FileOptimizer uses UPX under the hood. Many AV choke on UPX, but in this case, I had de-upxed the exe, and there was still a flag by Symantec. It could be the Virtual** stuff, which seems a FB feature - if I take away the pcre calls, they are still there.

Usually I'm coding on Win10 x64 and I cannot tell you why Win7 and XP isn't working properly but I will test it in my VMs to reproduce the issues

Your exe works just fine on W7 and XP. My exe didn't - but I found the culprit:

.lpszClassName = Strptr("#32770") ' this is UNICODE...CreateWindowEx(NULL, "#32770" ' this is ANSI

It seems that FB chooses ANSI/UNICODE somewhat arbitrarily; or maybe based on some IDE setting? In any case it's very messy.

My code, while supplying a UNICODE class name to RegisterClassA, managed to create a window because #32770 is a predefined window class (the dialog box, actually). So RegisterClassA succeeded for the class name "#" (the Ansi version of Unicode #32770), and CreateWindowExA succeeded for the dialog box class. And naturally, the .lpfnWndProc = Cast(WNDPROC, @WndProc) was simply ignored, and no messages arrived in that WndProc.

RNBW wrote:UEZI just wanted to show a different approach (PCRE) for the same "challenge" and that's the reason why I used same GUI and some functions from WinGUI.bi.I know it is very hard to learn regular expression but it can a mighty tool to have a simpler solution especially with string manipulation.

Counting lines with includes at the top makes not really sense as they are not visible.

My comments were not meant as a criticism. As I said it's good to see alternatives, but I found some of the code a bit difficult to follow. Also, I appreciate that the library I was using was a simplified version, but it's easy to understand and so I coded in that first. When I've got the extended version working properly (Numeric Entry Into A grid Of textboxes), I'll try some of the other libraries. The thing I liked about my code (which was an amalgamation of other people's code) is that it is short and can be used in another program without having too large an overhead.

Thank you again for your code. I've saved it and may come back to it again in the future.

No, I didn't understand it as a criticism, I just wanted to explain the reason why used regex. Apropos criticism, if the criticism is justified and it is politely communicated, then I am open to criticism at any time because I want to keep evolving.

jj2007 wrote:Actually, I wanted to post the Exe as Base91 code in the code box, so I tried to make the exe as small as possible using FileOptimizer, but I chose MediaFire. I cannot tell you why there are numerous calls to VirtualQuery and VirtualProtect in the code!

It seems that FileOptimizer uses UPX under the hood. Many AV choke on UPX, but in this case, I had de-upxed the exe, and there was still a flag by Symantec. It could be the Virtual** stuff, which seems a FB feature - if I take away the pcre calls, they are still there.

Usually I'm coding on Win10 x64 and I cannot tell you why Win7 and XP isn't working properly but I will test it in my VMs to reproduce the issues

Your exe works just fine on W7 and XP. My exe didn't - but I found the culprit: