PC Soft's WinDev, WebDev & Mobile vs VisualStudio

This is an old post - but in the 'Suggestions' list. Perhaps it should be included here in the main list as it may be quite topical now.

Link:

[www.wxforum.info]

Kind regards,
Guenter Predl
office@windev.at

I had a bit of a think about this.

The no dongle thing is a no-go for reasons that many have put forward.

I have had a look at some .NET interface samples - and a bit of a chat with CoPilot.

I think this is do-able.

Of course, C# and .NET is not a low-code replacement - but if you already have developed something substantial in WinDev - it's not really such a big leap to write in Visual Studio.

Just the last bit of my "chat" with CoPilot ... (these "AI" tools should help with the detail and any coding issues - you just have to be careful to ask the right questions!) :

Extending the Concept
Validation:

Build and test the prototype to ensure smooth integration and data flow between the Windows Form and the WinDev application.

Scalability:

If the prototype works as expected, you can extend this approach to other forms and functionalities, gradually migrating the UI to Visual Studio while retaining the business logic in WinDev.

Documentation:

Document the integration process, including the steps for creating DLLs, adding references in WinDev, and handling data exchange.

Community and Support:

Engage with the WinDev and .NET developer communities for support and insights. Sharing your progress and seeking advice can lead to valuable feedback and solutions.

By following these steps, you can validate the integration concept and create a robust framework for extending your applications using Visual Studio while maintaining your existing WinDev and WebDev infrastructure.

I had a little chat with AI regarding this no-dongle thing!.

Very circumspect response (of course) - but it really is a concern ...

PC Soft have recently changed their business model, and will no longer sell - or support - their product (s) sold as a "lifetime" sale to enforce an annual "saas" subscription model. A number of long-term small developers are quite concerned about this model, as it means that if at a future time they no longer continue with the subscription, then they will have no access to their own code base that they may have spent year or even decades developing, as well as all of the usual caveats that if there is an interruption in access to PC Soft servers, or some other possible scenario, including PC Soft going out of business, then all of their customers would also be out of business. This does seem like a most unusual business model. Should IT companies and developers (large or small) - be concerned with this, as it should be a primary responsibility of software developers to ensure that they can also support their own customers? Is it reasonably to sell software to customers when continued support can not be guaranteed, especially if that software is in turn crucial to the operation of these businesses. This seems quite unprecedented in IT. Is this an acceptable risk?


The shift from a "lifetime" sale model to a SaaS (Software as a Service) subscription model is indeed a significant change, and it raises several valid concerns for developers and businesses. Here are some key points to consider:

Concerns with SaaS Subscription Model
Access to Code Base:

One of the primary concerns is the potential loss of access to the code base if the subscription is not maintained. This can be particularly troubling for long-term projects where the code has been developed and maintained over many years.

Dependency on Vendor:

Relying on a single vendor for access to development tools and code repositories can be risky. If the vendor experiences downtime, goes out of business, or changes their terms of service, it can directly impact the ability of developers to support their own customers.

Cost Implications:

The shift to a subscription model can lead to increased costs over time. While a one-time purchase might be more expensive upfront, a subscription model can accumulate significant costs over the years.

Data Security and Privacy:

Storing code and development tools on external servers raises concerns about data security and privacy. Developers need to ensure that their data is protected and that they comply with relevant regulations.

Vendor Lock-In:

The SaaS model can lead to vendor lock-in, where it becomes difficult to switch to another provider due to the integration and dependencies on the current vendor's platform.

Benefits of SaaS Subscription Model
Continuous Updates and Support:

SaaS models often provide continuous updates and support, ensuring that developers have access to the latest features and security patches.

Scalability:

SaaS solutions are typically scalable, allowing businesses to adjust their usage based on their needs without significant upfront investments.

Reduced Maintenance:

The vendor is responsible for maintaining the infrastructure, which can reduce the burden on developers and IT teams.

Mitigating Risks
Backup and Redundancy:

Regularly backup your code base and maintain local copies to ensure that you have access to your work even if the vendor's service is unavailable.

Evaluate Alternatives:

Consider alternative tools and platforms that offer similar functionalities. Diversifying your toolset can reduce dependency on a single vendor.

Legal Agreements:

Review the terms of service and legal agreements with the vendor to understand your rights and obligations. Ensure that there are provisions for data access and portability.

Community and Open Source:

Engage with the developer community and explore open-source alternatives that provide more control and flexibility.

Conclusion
While the SaaS subscription model offers several benefits, it also introduces risks that developers and businesses need to carefully consider. Ensuring access to your code base, evaluating costs, and understanding the implications of vendor dependency are crucial steps in making an informed decision. It's essential to weigh the pros and cons and take proactive measures to mitigate potential risks.

If you have any more questions or need further assistance, feel free to ask!

Regarding point 1. You do have your own code base, but with the WinDev/WebDev model, but the code is useless without the IDE, which with the PC Soft SAAS model, is only useable if it can get a token from the PC Soft servers.


Ah, I see the dilemma. The dependency on the IDE and its reliance on obtaining a token from PC Soft's servers certainly adds an extra layer of concern, especially with the shift to a SaaS model. This scenario underscores the importance of having control over the development environment and tools.

Mitigating the Risk
Here are some strategies you might consider to mitigate this risk and ensure that you retain control over your development capabilities:

Local Copies and Backups:

Continue to maintain local copies and backups of your code base. While this doesn't solve the IDE access issue, it's still crucial for preserving your work.

Evaluate Alternative Tools:

Investigate and evaluate other development environments and tools that might offer similar functionalities to WinDev/WebDev but without the dependency on external servers for IDE access. Open-source tools might provide more control and flexibility.

Containerization:

Explore the possibility of containerizing your development environment. Tools like Docker can encapsulate your development setup, potentially including older versions of the IDE, ensuring that you have a consistent and portable environment.

Contracts and Service Agreements:

Negotiate service agreements with PC Soft that include clauses for extended access in case of service discontinuation or other disruptions. Ensure that these agreements are clearly documented.

Custom Tools and Extensions:

Consider developing custom tools or extensions that can interface with the code base independently of the IDE. This might involve additional development effort but could provide a safety net.

Legal and Community Action:

Collaborate with other concerned developers and businesses to present a collective case to PC Soft. Sometimes, user pressure can influence a company's policies or lead to more flexible solutions.

Moving Forward
The shift to SaaS models by software vendors is becoming more common, and while it offers certain benefits, it also brings challenges that need to be carefully navigated. By taking proactive steps, you can mitigate some of the risks and ensure continuity for your development projects.

If you need any more insights or assistance, feel free to reach out. Together, we'll find the best path forward for you and your development efforts. ????



Edited 1 time(s). Last edit at 03/07/2025 10:43AM by DerekM.

Hello Derek,

What a fascinating can of worms you have opened. I posed the same question to Deepseek - here is the answer - it is more direct in its opinions - see Final Thoughts at the bottom

Okay, let's see. The user is talking about a software development language provider changing their business model from a lifetime purchase to a SaaS subscription. The main concerns are that if developers stop paying, they lose access to their own code, and there's a risk if the provider's servers go down or the company goes out of business. The user is asking if IT companies and developers should be worried, and if selling software without guaranteed support is reasonable, especially when it's critical for businesses.

First, I need to break down the issues here. The key points are:

1. **Loss of Access to Code**: If the subscription lapses, developers can't access their code. That's a big problem because they might have years of work invested.

2. **Dependency on Provider's Infrastructure**: If the provider's servers have issues, developers can't work, and their customers are affected too.

3. **Business Continuity Risk**: If the provider goes out of business, everyone using their software is left stranded.

4. **Ethical Responsibility**: Should developers sell software to their customers when their own ability to support it is at risk due to dependency on a third-party provider?

I need to address whether these are valid concerns and if this business model is acceptable. Also, the user mentions this seems unprecedented, but I know SaaS is common, though maybe not in development tools where code access is crucial.

Let me think about similar situations. For example, Adobe moving to subscription model with Creative Cloud. Users were upset but adapted. However, in that case, files are still accessible even if you stop subscribing, just the software isn't updated. But here, the issue is that the code itself might be tied to the provider's platform. If the development environment is cloud-based, maybe you can't export the code? Or perhaps the code is stored on their servers?

So, if the development tool is entirely online, and you can't export your codebase, that's a major problem. Developers need to have control over their source code. Otherwise, they're at the mercy of the provider.

Also, from a business continuity standpoint, relying on a third party that could go under is risky. The user's customers depend on them, but if the provider fails, the whole chain collapses.

Another angle is the responsibility of software developers to ensure they can support their own customers. If their toolchain is unreliable, they can't guarantee support, which is unethical.

Possible solutions: The developers should look for alternatives that allow them to retain control. Open-source tools, or ensure that the provider allows code export and offline access. Maybe using version control systems that are independent of the provider.

Also, legal aspects: Were the terms of the lifetime license violated when the provider switched models? Maybe there's a breach of contract, but that depends on the original agreement.

In terms of industry norms, while SaaS is common, development tools often allow for local installations. Cloud-based IDEs exist, but they usually let you export code. If this provider is locking code in, that's not typical and is a red flag.

So, to answer the user: Yes, IT companies and developers should be concerned. It's a significant risk, especially for long-term projects. They need to ensure they have control over their code and toolchain. Selling software without a support guarantee is risky and could harm their reputation and liability.

The user might need advice on mitigating these risks: seeking alternative tools, negotiating with the provider, ensuring data sovereignty, or legal action if the terms were breached.

The situation you describe raises significant concerns for IT companies and developers, particularly regarding control, sustainability, and ethical responsibility. Here's a structured analysis and recommendations:
Key Concerns

Loss of Access to Code:

Developers risk losing access to their codebase if subscriptions lapse, which is unacceptable for mission-critical projects. Code ownership and portability are fundamental principles in software development. If the toolchain locks code into a proprietary platform, this violates standard practices.

Dependency on Provider’s Infrastructure:

Reliance on third-party servers introduces single points of failure. Downtime, cyberattacks, or service discontinuation could halt development and disrupt downstream customers.

Business Continuity Risks:

If the provider shuts down, developers and their clients face existential risks. This creates a liability chain, especially for small developers who may lack resources to migrate swiftly.

Ethical and Professional Responsibility:

Developers have a duty to ensure their tools do not jeopardize their ability to support clients. Selling software built on unstable foundations risks breaching trust and contractual obligations.

Industry Context

SaaS Trends: While SaaS models are common (e.g., Adobe Creative Cloud), development tools typically allow local code storage and export. Locking code into a cloud-only platform is atypical and raises red flags.

Precedents: Similar controversies arose when Parse shut down (2016), forcing developers to migrate. However, Parse provided ample notice and migration tools, which may not be guaranteed here.

Is This an Acceptable Risk?

No, especially for long-term or business-critical projects. Key reasons:

Loss of Autonomy: Developers cannot guarantee product longevity if their tools are contingent on a third party’s survival.

Ethical Liability: Selling software without a contingency plan for provider failure risks harming clients’ operations.

Reputational Damage: Dependency on unstable tools undermines developer credibility.

Mitigation Strategies

Evaluate Alternatives:

Transition to tools with offline access, open-source options, or lifetime licenses. Prioritize platforms allowing code export and local backups.

Negotiate with the Provider:

Demand contractual assurances (e.g., data escrow, code ownership clauses) or discounts for long-term subscribers. Collective bargaining with other affected developers may increase leverage.

Legal Review:

Investigate whether the shift breaches prior "lifetime" license agreements. Legal action or refund claims may be possible.

Decouple from the Provider:

Regularly export code and assets to independent repositories (e.g., GitHub, GitLab). Automate backups to ensure continuity.

Client Communication:

Inform clients of risks and contingency plans. Transparency builds trust and mitigates liability.

Advocate for Industry Standards:

Push for tools adhering to principles like the Customer’s Bill of Rights for Software, ensuring data ownership and portability.

Conclusion

This business model shifts excessive risk onto developers and their clients. While SaaS subscriptions are not inherently problematic, the lack of code ownership and continuity planning makes this approach unsustainable. Developers should treat this as a critical threat and act proactively to safeguard their work and clients. The precedent set here could encourage similar practices industry-wide, making resistance and mitigation essential for long-term stability.

I added the next comment and regenerated an answer
The IDE is on local PC's, that must login to the development language provider to receive a token to enable the IDE to work.

Okay, the user provided additional information that the IDE is installed locally but requires logging in to get a token. Let me digest that.

So, even though the IDE is on the local PC, it needs a token from the provider's server to function. This adds another layer of dependency. The previous concerns about losing access if the subscription lapses are still valid, but now there's a twist with the token requirement.

Hmm, the main issue here is that the IDE becomes unusable without that token. Even if the code is stored locally, if the token expires or the provider's servers are down, developers can't work. That's a critical point.

I need to break down the implications. First, token dependency introduces a single point of failure. If the provider's authentication servers go down, even temporarily, work halts. Also, if the company goes out of business, the token service stops, rendering the IDE useless.

The user is likely worried about business continuity. They might be a developer or manage a team that relies on this setup. They need to ensure that their development environment remains functional regardless of the provider's status.

I should address both immediate and long-term risks. Maybe suggest ways to mitigate the token dependency. Perhaps looking for tools that don't require constant authentication, or finding a way to cache tokens, though that might be against the provider's terms.

Also, legal aspects come into play. If the provider previously sold lifetime licenses, switching to a token-based subscription model might breach previous agreements. The user could have legal recourse here.

Another angle is exploring alternatives. Are there other IDEs or languages that don't have this token requirement? Migrating might be a hassle, but it's better than being locked in.

Communication with clients is key too. If the development team can't work, their clients are affected. Transparency about these risks is important to maintain trust.

Backup plans are essential. Maybe setting up a secondary development environment with a different toolchain to switch to if the primary one fails. Regular code exports to ensure that even if the IDE stops working, the codebase isn't lost.

I should also mention checking the provider's terms of service. There might be clauses about service discontinuation or data ownership that could be leveraged. Maybe the provider offers some form of escrow for tokens or code in case they shut down.

Lastly, community action. If many developers are affected, banding together to negotiate with the provider or even creating a fork of the language/tools if possible. Open-source alternatives could be a solution here.

Need to structure the response to address these points clearly, offering practical steps while validating the user's concerns. Make sure the advice is actionable and covers both technical and strategic angles.

The additional detail that the IDE is locally installed but requires authentication via a provider-controlled token to function introduces even more critical risks. This setup effectively creates a "kill switch" controlled by the provider, which amplifies the concerns about business continuity and autonomy. Here’s a breakdown of the implications and actionable steps:
Key Risks of Token Dependency

IDE Functionality Tied to Provider’s Servers

Even with local installation, the IDE cannot operate without periodic token validation. If the provider’s authentication servers go offline (e.g., due to outages, bankruptcy, or policy changes), the IDE becomes unusable, halting all development.

Subscription Lapse = Immediate Work Stoppage

If a developer stops paying the subscription, the token will eventually expire, locking them out of their own tools and codebase. This creates a hostage-like relationship with the provider.

No Offline Fallback

Developers in low-connectivity environments (or regions with internet restrictions) are vulnerable. A lack of offline authentication undermines productivity and reliability.

Vendor Lock-In at Scale

Over time, migrating to another toolchain becomes harder due to codebase dependencies on proprietary frameworks or libraries tied to the provider’s ecosystem.

Is This Acceptable?

No. This model violates core principles of software ownership and developer autonomy. While SaaS tools often require authentication, development tools (especially IDEs) are expected to function offline or provide failsafes to avoid holding code hostage. Examples like JetBrains IDEs (e.g., IntelliJ, PyCharm) allow offline activation or perpetual fallback licenses for older versions, balancing SaaS convenience with user control.
Immediate Mitigation Strategies
1. Demand Offline Licensing or Token Independence

Petition the provider to offer:

Offline activation codes (valid indefinitely).

A "fallback mode" allowing the IDE to function with reduced features if tokens expire.

Perpetual licenses for existing customers who purchased "lifetime" access.

Collective action: Organize affected developers to pressure the provider as a group (e.g., petitions, social media campaigns, or legal threats).

2. Decouple Code from the Provider’s Ecosystem

Export code regularly: Ensure codebases are stored in version control (e.g., GitLab, GitHub) outside the IDE’s proprietary ecosystem.

Avoid provider-specific frameworks: Refactor code to use open standards or portable libraries (e.g., JSON, SQLite) instead of proprietary APIs.

3. Prepare for Workarounds

Reverse-engineer token validation: While ethically and legally fraught, some developers might explore patching the IDE to bypass token checks. This risks lawsuits or malware concerns.

Virtual machine snapshots: Freeze a working IDE environment in a VM with a valid token, but this is a short-term fix (tokens may still expire).

4. Legal Action

Review original "lifetime" license agreements: If the provider sold "lifetime" licenses but now requires subscriptions, this may breach contractual terms. A class-action lawsuit could force refunds or grandfathering.

Regulatory complaints: In the EU, argue that token dependency violates GDPR’s data portability principles or consumer protection laws.

5. Transition to Alternatives

Identify competing tools: Migrate to IDEs/languages with similar features but no token requirements (e.g., VS Code, Eclipse, or open-source languages like Python/Java).

Prioritize offline-first tools: Choose frameworks that don’t mandate cloud dependencies (e.g., C#, Rust, or JavaScript).

Long-Term Solutions

Push for Industry Standards

Advocate for developer tools to adopt the Principles of Ethical Software Licensing, ensuring users retain control over their workflows.

Build Contingency Clauses into Client Contracts

Explicitly state that your tools are subject to third-party risks, and outline contingency plans (e.g., migration timelines) if the provider fails.

Invest in Open-Source Alternatives

Support or contribute to open-source IDEs/languages (e.g., Apache NetBeans, Code::Blocks) to reduce reliance on proprietary vendors.

Why This Matters Beyond Small Developers

Enterprise risks: Large companies using this toolchain inherit the same vulnerabilities. A provider’s bankruptcy could disrupt entire industries.

Ethical responsibility: Developers have a duty to avoid tools that jeopardize their clients’ operations. Selling software built on such a fragile foundation is ethically questionable.

Final Thoughts

The provider’s model is not just "unusual"—it’s predatory, holding developers’ work hostage to enforce subscription compliance. While SaaS is here to stay, mission-critical tools like IDEs must prioritize user control. Developers should treat this as an existential threat and act immediately to:

Secure code ownership.

Reduce dependency on the provider.

Prepare for migration.

The longer teams wait, the harder it becomes to escape lock-in. Transparency with clients and proactive planning are essential to maintain trust and operational resilience.



Edited 1 time(s). Last edit at 03/07/2025 11:51AM by Al.

I had forgotten about DevExpress.

Lots of things can be done with free/open source - but much of the "ease of use" and feature rich WinForms stuff can all be done easily with DevExpress.

NOT SO CHEAP - however no lock-in.

(I checked this with copilot) :

With DevExpress products - if you do not renew the annual subscription - then you are free to continue indefinitely with the product that you purchased (unlike WinDev SAAS) ?


Yes, with DevExpress products, if you choose not to renew your annual subscription, you can continue using the last version you obtained indefinitely. The subscription model provides access to updates and technical support for 12 months, but once it expires, you retain the right to use the version you had at the time of expiration2. However, you won't receive any new updates or support unless you renew the subscription.

This is indeed different from a SaaS model like WinDev's, where access to the IDE itself might be restricted if the subscription lapses. Let me know if you'd like to explore more about DevExpress or other alternatives!



Edited 1 time(s). Last edit at 03/21/2025 12:56AM by DerekM.

And now I have to investigate the DevExpress XAF Framework,

There may indeed be "WinDev" without PCSoft !!!

Are there any in-depth reviews of DevExpress perhaps comparing this environment with WinDev ?


While there are reviews and comparisons of DevExpress and other tools, direct comparisons between DevExpress and WinDev are less common. However, here are some insights based on available information:

DevExpress:

Known for its extensive suite of UI components for .NET, WinForms, WPF, ASP.NET, and Blazor.

Offers tools like XAF (eXpressApp Framework) for rapid application development, which is somewhat comparable to WinDev's RAD capabilities.

Highly praised for its polished UI components and strong customer support, though some users find the learning curve steep for beginners2.

WinDev:

Focuses on rapid application development with its integrated environment, including the Analysis feature for data modeling.

Offers a unique all-in-one approach, combining IDE, database management, and deployment tools.

Some users appreciate its simplicity for building data-intensive applications, but others find its proprietary nature limiting compared to more open ecosystems like .NET.

Key Differences:

Ecosystem: DevExpress is tightly integrated with Visual Studio and the .NET ecosystem, while WinDev is a standalone environment.

Flexibility: DevExpress allows you to work within the broader .NET framework, giving you access to a wide range of libraries and tools. WinDev, on the other hand, is more self-contained.

Subscription Models: As you mentioned earlier, DevExpress allows indefinite use of purchased versions, whereas WinDev's SaaS model requires an active subscription.

If you're considering transitioning from WinDev to DevExpress or Visual Studio, it might be worth exploring DevExpress's XAF framework, as it provides a similar RAD experience. Let me know if you'd like help finding more specific resources or reviews!

I'm getting a bit ahead of myself (at least 6 months down the track) - but at least I can stop panicking.

I've had a brief look at all the key techniques and technologies that I need to eventually escape the PCSoft black hole: -

Everything that I need and am comfortably with in WinDev/WebDev (the SCM, Analysis, cross-platform, multi database targets, SaaS, RAD, shared code for WinForms and Web Pages) - can quite readily be done without the largess of PCSoft.

Good grief - I have no idea why they think that anyone investing man-years of development work would be happy to have it all ride on the back of a token from Montpelier.

Derek

SteveSitas mentioned XOJO as a dev tool worth looking at. It is indeed very impressive and, like DevExpress, you can continue to use the version you were on after ending a subscription; you can still use the full solution but just without updates. They have full cross-platform development (desktop, web, mobile) and support all major O/S environments (Windows, Linux, iOS), have a long history of being in business, and looks like a very polished product.

Hi JP.

Yes - had a quick look at XOJO - looks quite good.

The Ultimate choice will depend on individual requirements.

This has been around since 1997 (2013 in current format).


An interesting fact here though: +450,000 users | millions of apps created.

I may be wrong - but that seems to be a little bit more than the number of WinDev users.

Derek,

Yes that's what caught our eye too; that's a lot of users ( == safety in the product continuing) and long history ( == mature, reliable software). We are very impressed and will be buying a copy and exploring the platform further - if for nothing else than its always fun to play around with new things. And, yes, you are right, every platform is a choice driven by each developers particular situation and requirements.

I like the WX products but we have to have continued access to sources and ability to use a product even after ending a subscription (albeit without further updates). What I found truly wild is the dongles will be downgraded to only work with version 23 if the WX subscription stops. If you "upgrade" (i.e. downgrade) your dongle to subscription model, you get a one-time discount on the subscription - LOL !. I am never going that route because I have paid for version 24, 25, 26, 27, 28, 29, and 30 and I am not going to give up thousands of Euros of upgrades for a one-time discount to the subscription model and then also lose access to my sources and ability to work with them if I stop subscribing. Here's the link: [windev.com] - look under question "I own dongles ..."

Hi Derek and JP,

1. You can start with Syncfusions controls instead of DevXpress.
They are free to use and free to distribute your apps that include them, IF you are a company with less than 1 million $ revenues.
I have used and purchased both of them in the past, but I prefer Syncfusion.

2. Another product I purchased and used in the past is Infragistics. Now days they even have an app builder - but I didn't have time to test it.

3. I tried al the above products when I was moving away from Clarion - but after I spent nearly 5.000 $, I "found" Windev !!!
What bothers me with the above is Microsoft .net - maybe with .net core things are now better ...

4. Xojo is a great second developers tool - it has the right price, you can create apps with the trial version (you just cant compile them) and it has a huge following (probably 3 or 4 more users than WINDEV).

5. The only thing I miss with Xojo is WINDEVs table/grid - there are some 3rd party grids but I am waiting for Xojos native implementation.

6. Take a look at no-code tools: I am currently evaluating "bubble".
7. Take a look at AI tools: I am currently evaluating "loveable".

At the end I would like the new MANAGEMENT at PCSoft to find a way - at least for old customers - to continue working with dongle versions.
But since clarions "demise", I am now more "wise" and ready for whatever comes ..

Regards
Steven Sitas

Hi Steven

Thank you very much for that information.

On your recommendation, I will start with Syncfusion.

From a brief initial query - it seems that it may be more effective in achieving some of my goals that DevExpress (cheaper too).

I intend to plan this migration over the next 6 months - not 'DO' the migration - just "plan it".


One of my first jobs is to ensure that I can handle all of my existing data (e.g. circa 900 data files, 1000 Queries etc.) in a fashion similar to WinDev's abstraction layer - so that I can easily convert the business logic contained in several hundred procedures.

The Syncfusion Query Builder also sounds good.

[coPilot on one of my queries originally looking at DevExpress]

Yes, you can achieve similar results with **Syncfusion**, as it provides robust data management and UI components that can streamline CRUD operations and query handling. While Syncfusion doesn't replicate WinDev's exact query management system, it offers tools that can help you build a comparable solution.

### Key Features of Syncfusion for Data Management

1. **DataManager**:
- Syncfusion's **DataManager** is a powerful tool for managing data operations like sorting, filtering, paging, and CRUD (Create, Read, Update, Delete).
- It supports integration with various data sources, including REST APIs, databases, and local data.

Example:
```javascript
var dataManager = new ej.data.DataManager({
url: "[your-api-endpoint"];,
adaptor: new ej.data.WebApiAdaptor()
});
```

2. **Grid Components**:
- Syncfusion's **Data Grid** components (available for frameworks like React, Angular, Vue, and Blazor) allow you to bind data seamlessly and perform CRUD operations with minimal code.
- Features include inline editing, batch editing, and support for remote data sources.

Example (React):
```jsx
<GridComponent dataSource={dataManager} allowPaging={true} allowSorting={true}>
<ColumnsDirective>
<ColumnDirective field="ID" headerText="ID" width="100" textAlign="Right" />
<ColumnDirective field="Name" headerText="Name" width="150" />
<ColumnDirective field="City" headerText="City" width="150" />
</ColumnsDirective>
</GridComponent>
```

3. **Query Builder**:
- Syncfusion includes a **Query Builder** component that allows users to visually create and manage queries. This is particularly useful for building dynamic queries without writing SQL manually.

4. **Custom Data Adapters**:
- Syncfusion's DataManager supports custom data adapters, enabling you to define how data is fetched, processed, and updated. This flexibility can mimic the behavior of WinDev's query system.

5. **Integration with ADO.NET or Entity Framework**:
- You can use Syncfusion components alongside ADO.NET or Entity Framework to manage data access and queries. For example, you can bind a Syncfusion Data Grid to an EF data source for seamless CRUD operations.

### How It Compares to WinDev
- **Ease of Use**: Syncfusion provides a visual and code-driven approach to data management, similar to WinDev's simplicity.
- **Flexibility**: Syncfusion's tools are highly customizable and can integrate with modern frameworks and APIs.
- **Scalability**: Syncfusion is well-suited for large-scale applications with complex data requirements.

---

If you're transitioning from WinDev, Syncfusion's components can provide a familiar and powerful environment for managing data and queries. Let me know if you'd like help setting up a specific example or exploring Syncfusion further!

---

Hi Derek,

Imho, the price of Syncfusion with US$ 395 / MONTH is prohibitive ... if you buy that then you could stay with WX anyway!? What's the positive difference there?

Kind regards,
Guenter Predl
office@windev.at

gpredl Wrote:
-------------------------------------------------------

> Imho, the price of Syncfusion with US$ 395 /
> MONTH is prohibitive ... if you buy that then
> you could stay with WX anyway!? What's the
> positive difference there?

Hi Guenter.

The price is actually a secondary issue. The primary issues are:

1) The loss of access to one's own source code and the ability to continue to use the version of WX software up to the point of ending a subscription, and

2) The destruction of the dongles ability to use versions of WX later than 23 even though one has paid in full for a lifetime license to versions 24, 25, 26, 27, 28, 29, and 30 and which all came with the promise of replacement dongles. Plus, even if the dongle still allows access to version 23 (i.e. a 7 year old version of WX) it will not open later version projects so the version 23 dongle will be effectively useless/worthless.). And, if you lose that dongle or it breaks then PCS will not replace it apparently. So you will again be stuck ...

These 2 issues are, for us, deal breakers. We will be looking for alternate solutions unless something changes at WX/PCS.

And then there is the conversion of lifetime license of WAS into a monthly charge, which, I assume, when one stops paying the WAS subscription will mean your websites stop working. And you will be forced to go subscription model on the WAS if you go subscription on WebDev because the one requires the other.

Of course, my comments above are based on what I have read in this forum by other (prominent) users and from my understanding of what is read on the PCS website. If I have not understood something correctly then I truly welcome to be corrected because we also have a reasonably large investment in WX platform. But if I understand this correctly then we will be moving to another development platform, for sure.

In respect of price for a service like SyncFusion: The price one pays for any service is acceptable depending on whether the service provided creates more value than the price paid. I will pay $10,000 per month for a development service if it allows me to make $11,000 in revenue. I don't know about SyncFusion, however, so I am making just a general comment about the principle of paying for a service.



Edited 4 time(s). Last edit at 03/22/2025 04:48PM by JP.

Hello JP,

The new owners of PCSoft have neatly side stepped the royalty free provisions of the original licence by introducing subscriptions for the WAS and also the Native connectors so our clients will end up paying the subscription to keep running the Saas derived software they purchase from us.

If I had a client running the WAS and an MS SQL native connector on a Webdev site, the yearly subscription fee to my client would be A$1,380 dollars!

I would not bet against a move later on to impose a subscription fee on using the HFSQL and how much longer will the free native connectors be supported ?

I am lucky that I stopped developing at V25 but If I have to do any future programing I will have a serious look at Delphi.

Regards
AL

Al,

The more I think on this whole change the more I come to the conclusion that simply as a matter of principle we will no longer upgrade our WX licenses and will not further develop in WX - 90% sure that is now our position unless something drastic changes. We will be moving to another platform and currently I do like Xojo with the BasicApp Xojo DataGrid add-on. We like their licensing models; ability to continue to use whatever version you have when subscription ends, large developer community, long history of being in business, royalty free distribution, multi-platform support for both the developer and the end-user, etc. We are looking into it, we'll see.

It sees windev has some 150.000 licenses. If you ask deep seek then windev is not really comparable with xojo . Windev is for enterprice apps xojo not.

But it say till about 50 users an app can be made with xojo .Plus if youneed more then you canuse xojo for front end communicatining with a backend in python microservices kind of dong things .

Interesting as the front is drag drop . and onley 99 dolar per year .