NetBarCodeV1.06 Zxing

what is the advantage compared to famous https://github.com/VFPX/FoxBarcode (with FoxBarcodeQR) or https://github.com/atlopes/zintbarcode ?

比二者对比，它支持格式更多，参数更全面，是工业级条形码首选，支持格式如下：

专业级参数如下：

@iswithzhz
Please stop your one way communication here. So far you haven't answered a single question, as far as I have seen. Instead you keep on pushing new, more or less meaningless, messages. If this continues, I will ask to have you banned.

我怎么没有回答！请问，哪里没有问答，你是不是对汉语有成见

This is an English speaking forum, please follow the forum's rules.
And, when someone asks a question, please be polite and answer in English.

Okay! I respect the rules and will answer in English.

* - Class Name: NetBarCode
* - Parent Class: Custom
* - Description: Generates barcodes using the C# NetBarCode component
* - Dependencies: C# 4.6.1, NetBarCode.dll (v1.06) | ClrHost.dll (v7.29)
* - Author: ZHZ
* - Architecture Design:
* - Barcode Generation: Supports multiple barcode formats (QRCode, Code128, etc. - see _BarcodeFormat)
* - Creation Date: 2025-06-17
* - Version: 1.06
* - Removed BarCode recognition functionality - pure BarCode generation only
* - Format Application Scenarios:
* 1. AZTEC (1) : Transportation tickets (e.g., European railway systems)
* 2. CODABAR (2) : Library management, blood banks (legacy systems)
* 3. CODE_39 (4) : Industrial applications, automotive part identification (alphanumeric support)
* 4. CODE_93 (8) : Canadian postal services, logistics and inventory management
* 5. CODE_128 (16) : Logistics and shipping (e.g., courier waybills)
* 6. DATA_MATRIX (32) : Small item identification (electronics components, pharmaceutical packaging)
* 7. EAN_8 (64) : Small retail products (e.g., chewing gum, candy)
* 8. EAN_13 (128) : Retail products (supermarket goods, books, food)
* 9. ITF (256) : Shipping container labeling (corrugated boxes)
* 10. MAXICODE (512) : UPS package sorting
* 11. PDF_417 (1024) : Driver licenses, IDs, boarding passes (high data capacity)
* 12. QR_CODE (2048) : Mobile payments, advertising (e.g., WeChat Pay codes)
* 13. RSS_14 (4096) : Small items (e.g., medicine bottles) - GS1 DataBar format *** Requires dynamic extension package
* 14. RSS_EXPANDED (8192) : GS1 DataBar for perishables (e.g., produce) *** Requires dynamic extension package
* 15. UPC_A (16384) : US/Canada retail products (supermarket goods)
* 16. UPC_E (32768) : Compact UPC for small products (e.g., cosmetic samples)
* 17. UPC_EAN_EXTENSION (65536) : Magazine/book supplements (issue numbers/prices) *** Requires dynamic extension package
* 18. MSI (131072) : Warehouse inventory management (legacy systems) *** Requires dynamic extension package
* 19. PLESSEY (262144) : Shelf labeling, libraries (legacy systems)
* 20. IMB (524288) : USPS Intelligent Mail barcode *** Requires dynamic extension package
* 21. PHARMA_CODE (1048576) : Pharmaceutical tracking *** Requires dynamic extension package

I'm glad to see that you finally post in English.
However, your earlier postings have resulted in several questions which still remain unanswered. It would be very nice if you spent the time to check, and answer them.

To be honest, I used AI for translation! My English isn't great, but I'll work hard to learn it and become the "coolest kid" in the "VFP Village"!

Well, second coolest, with . . . um . . . eh-hem . . . me being the coolest.

It's clear to see you can bridge between VFP and .NET.

What you lack is not only learning English, though, as I said in a previous thread, I think you should partner up with someone that doesn't only act as a translator but also help with public relations. Doing the translation part with AI is not a bad idea and works better than the traditionally grown Google Translate (I bet that's also powered by Gemini AI by now, though). But it's obvious you overlooked the questions of Tom and even if not, your answers didn't come over as the core of what he'd like to know.

It also seems you either don't know much of the existing VFP third party add ons or the opposite: You aim at replacing them with one new set of all .NET based projects that are leveraged with your own, new, improved bridge to .NET.

I wonder if you actually use Rick Strahls .NET bridge as ClrHost.dll is familiar from that, too, or whether you used something else, too. I know there is a bridge to another great realm, namely Javascript it goes quie a few steps, though:

Which makes use of a Javascript runtime called kawix.

So that's bridging to Javascript and node.js and everything related to the JS world, obviously. It's quite a humungis base for running some of the Shide based things like mail, web requests, zip and JSON, but obvioulsy the .NET framework is also quite humungus, just already on board every Windows computer.

Well, you're not alone in offering for the same topics as others again and again, and that's what's also disappointing, even if everything we know and use with VFP would come out of the hands of one single developer to make it overall a more homogenous integration. It's clear you're leveraging other projects and thus it will not become something uniformly with one such seamless interface. I would also say you're not the only one that can bridge to .NET as we already have the .NET bridge from Rick Strahl available, even if there still are doubts from some it would stop working in later .NET versions, the mechanism of bridging towards other worlds remain untouched.

"Actually, I might be more familiar with all known third-party VFP solutions than most. So why develop new tools? The reasoning is simple: On the .NET platform, stability, performance, and implementation simplicity surpass all previous approaches – with the exception of my WebView2 implementation.

Take NetJson as an example: Its core consists of just two DLLs (ClrHost.dll/NetJson.dll) and one PRG file. It achieves seamless conversion between cjson ↔ ojson, while preserving VFP's native Addproperty() logic for node manipulation before osjon → cjson conversion. It passes all 14 sample cjson tests (including high floating-point edge cases, though '3.4028235e38' fails due to specific technical reasons). Performance is excellent, and implementation aligns with my core design philosophy: Simplicity First.

Regarding Rick Strahl's .NET bridge – while I acknowledge its existence, my design evolved through China DeepSeek optimizations. Though ClrHost.dll references West Wind concepts, our implementations differ fundamentally. A simple example: ClrUnload handles memory completely differently. My approach ensures full memory reclamation, leaving VFP pristine. I encourage you to compare both architectures.

Recently, I developed NetClearScript for VFP – a groundbreaking approach enabling three languages to interoperate seamlessly. Calling C# through this framework is far simpler than any existing VFP/C# bridge. Observe this implementation:

Is sending emails with attachments now simpler than ever before?

Please note that the modules I publish are only intended for learning, research, and communication in a development environment. They are not to be used for commercial purposes when packaged into an EXE.

Tore Bleken said:

This is an English speaking forum, please follow the forum's rules.
And, when someone asks a question, please be polite and answer in English.

Click to expand...

Translated above reads: "Why didn't I answer? Excuse me, where is the question and answer? Do you have a prejudice against Chinese?"