Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
WinDev Forum
Beiträge im Thema:
12
Erster Beitrag:
vor 1 Jahr, 1 Monat
Letzter Beitrag:
vor 1 Jahr, 1 Monat
Beteiligte Autoren:
Yogi Yang, Fabrice Harari, GuenterP, Peter Holemans, kingdr

Age of WinDev???

Startbeitrag von Yogi Yang am 25.06.2016 04:28

Any ideas as to how old WinDev actually is.

I mean as to when was it actually launched to the public be it French or English...

And when was the first English version released?

Just curious....

Antworten:

pcSoft formed in 1984, 100% in French mode.

See this link as below:
https://fr.wikipedia.org/wiki/WinDev

They called it HyperScreen in English for DOS mode while I was evaluating Magic software, CTREE, Clipper, MUFO and Dataflex at the same time ~ 1988-89.

So I thing 1996-7 (Windev 5.5) till now (21) are running good product indeed.

2016-1993=23 years

and yet still is a good product indeed.

Cheers

King

von kingdr - am 25.06.2016 06:22
King,

Thanks for your reply and for educating me.

After 20+ year WD is a marvelous product that is really usable and truly productive!!

But even after all these years PCSoft has not really learned much it seems. There is still no officially released support for building native (third party) components.

Something like a SDK that developers can use to build native components. For example WD does not have support for image processing. If there were facility to build native third party components in other languages one would surely add such support.

on reading above lines most of you would say in unison that WD supports .NET components as well as ActiveX but after extensively testing these features I can say not all types of ActiveX are usable! Esp. using those which communicate with hardware like finger print readers, bio-metric devices, medical equipment that provide live feeds in real time, etc.

That same thing applies to .NET components. Yes it handles those components which do not have or require any UI. But otherwise there are a lot of problems. Try to use DevExpress XAF.

And some of the components provided are really quite limited or very buggy to use in production, the moment you try to use them in their full capacity like for example the FTP component.

So ultimately we are always at mercy of PCSoft for components.

I am surprised that even after all these years PCSoft has not really learned to open up and allow third party develops to create native components!

20+ years and there is still no support to build IDE add-ins/plugins so that we can solve the problems that the IDE has or make the IDE do certain thing the way we want or better still enhance it and take it to a higher lever using our own add-ins/plugins.

Let me list a very basic and very useful feature requirement, but that is sorely missing in the IDE.....

We cannot save or export the project in a textual (human readable) format so that it is portable across versions or across the same version that is between French version and English version and Chinese version.

Look at other development environments like Visual Studio, Delphi, Omnis Studio, etc. they have facility to build and use third party components, IDE add-ins/plugins, etc.

Any idea as to why? Why has PCSoft still not learned to open up a bit?!?!?!?!?

Come on PCSoft learn something from your competitors.

Note: I am not criticizing I am just putting my views and thinking aloud.....coz I think now it is the right time for them to open up a bit....

von Yogi Yang - am 25.06.2016 09:31
Hi, there was even a WINDEV 3 and 4 before that. I bought my 5.5/US in 1999, the first release of WINDEV in English. WD 5.5 is still a stable product and can do a lot of things which other 4th GLs cannot. Btw, there is a hidden 32-bit WDMODFIC.exe, which is very useful. Then, there was WINDEV 6 which actually never saw the market, then a short blink of a WINDEV 7, after that came WINDEV 7.5 which seemed to be the first running and usable 32-bit WD. From 7.5 on WINDEV 8 happened to be really good and could be trusted in.

von GuenterP - am 25.06.2016 10:26
Hi

my two cents...

I started with windev 1.5 in 93. So Windev 1 is from 92 or 93.

As for your laundry list:
- We cannot save or export the project in a textual (human readable) format so that it is portable across versions or across the same version that is between French version and English version and Chinese version.

True, we cannot do it. Why? Probably because: 1. It would crash their EXPRESS version protection.
2. we don't really need it: French US and (I suppose) Chinese version are strictly equivalent. You can open the same project in all version (and even translate the code automatically). Furthermore, going BACK to a previous version is something rarely needed. That's what backups are for (and windev is making an automatic backup before migrating).

- Look at other development environments like Visual Studio, Delphi, Omnis Studio, etc. they have facility to build and use third party components, IDE add-ins/plugins, etc.

I'm using components all the time. ActiveX, .Net, dlls, WinDev made components, I've connected WinDev programs to many kind of hardware through all types of SDKs and APIs, and as of now (25 years later), I have yet to encounter a project I could not complete one way or another... So you may be very unlucky, or you may be missing some pieces of information for this kid of projects, but I do not think that your experience represents the experience f the majority of WinDev developers.

Now, I DID hear of things that some developers could not make work on different forums, but as they did not ask for my help on the subject, I cannot say if there was a solution or not... However, my experience (and the experience of other developers I'm working with quite often) says that this specific problem is extremely limited, which may explain why what you are requesting here is not done.

Best regards

von Fabrice Harari - am 25.06.2016 11:28
Hello,

- We cannot save or export the project in a textual (human readable) format so that it is portable across versions or across the same version that is between French version and English version and Chinese version.

True, we cannot do it. Why? Probably because: 1. It would crash their EXPRESS version protection.
2. we don't really need it: French US and (I suppose) Chinese version are strictly equivalent. You can open the same project in all version (and even translate the code automatically). Furthermore, going BACK to a previous version is something rarely needed. That's what backups are for (and windev is making an automatic backup before migrating).


Fabrice, you do have a point here... But then they can always restrict express edition from opening human readable format projects.

I have run into problems opening/converting WD15 (French Edition) projects in WD17 (English Edition).... So I don't agree with you on this ground... And error message given is very obscure. Even trying to open one single code module (.wdg) and it fails. Now from what little WD I know a module does not have any UI related info to not map.

As for backward thing. It is requied. For example I cannot open your WXEDM project in WD17 coz you are using the latest version and producing the project using that version. Now if I want to access the code to study good programming practices that you have implemented into it I can't. But if there was support for human readable format I would have easily managed to open your project and study some really good coding practices.

I'm using components all the time. ActiveX, .Net, dlls, WinDev made components,...
Yes one can only make component using WD or one has to use either ActiveX or .NET DLLs. But in case of say for example ActiveX one can build one using VB6, Delphi, C++, FPC, PureBasic, PowerBasic, etc. can we make WD components using any such other languages. The answer is NO!. This openness is required. In fact just opening this up will spin up an industry of component creators.

As I had said in my post. Try to use DexExpress's (component set name DXperience) XAF in WD and you will understand that the support for .NET components is very rudimentary. I think the reason this is so is coz WD does not implement WinForms completely internally for all types of .NET components to work properly.

Finally I will repeat that the IDE need to be opened up a bit so that we can build add-ins/plugins. What do you say about this?

Regards,

von Yogi Yang - am 27.06.2016 05:38
Hi Yogi,

It may finally come although I'm afraid it will not be as open as we all want... I too requested to open up the WX file formats like m$ has done more than a decade ago with all its proprietary formats. It would allow to grow a community that adds value to the complete technology WX stack by providing add-ons and/or code generators.

On the other hand, I have a semi-confirmation that the ability to generate custom WDC (class) files out of the editor by code may be included in WX22. This is still unconfirmed but I understood it is something that is really being looked at for the next version after I've been repeatedly requesting such a feature since V17. It means that we would be able to generate at least one or some types of WX files ourselves without having to go through the editor...

It is the community that in part decides the direction the product evolves too, so if we massively suggest to open up the PCSoft file formats (like any vendor has done over the last decade) it may be included one day or another...

So guys, go ahead and make those suggestions!

Just my 2 cents,

Peter Holemans

von Peter Holemans - am 27.06.2016 07:15
Hello Peter,

Actually I started this thread hoping that the community will chime in and ultimately it will have some impact on PC Soft to implement some of the things discussed.

But the community seems to be silent at large :confused:

This could only mean either they are happy with what they have or are turning a blinds eye towards it.

Anyways let us try... :spos:

Regards,

von Yogi Yang - am 27.06.2016 08:37
Hi again

Fabrice, you do have a point here... But then they can always restrict express edition from opening human readable format projects.

True, they can... however, if there is no real need...

I have run into problems opening/converting WD15 (French Edition) projects in WD17 (English Edition).... So I don't agree with you on this ground... And error message given is very obscure. Even trying to open one single code module (.wdg) and it fails. Now from what little WD I know a module does not have any UI related info to not map.

I have never had the case myself and have been converting from windev 1.5 forward for the last 20+ years... What you are describing comes generally (as I did solve this kind of problems for my customers) from a BROKEN old project that needs to be corrected before migrating. It happens between french version the same way as between fr/us versions. So the language is not important here.

As for backward thing. It is requied. For example I cannot open your WXEDM project in WD17 coz you are using the latest version and producing the project using that version. Now if I want to access the code to study good programming practices that you have implemented into it I can't. But if there was support for human readable format I would have easily managed to open your project and study some really good coding practices.

No it's not... If you just want to study the code, ask for a project report containing it as pdf from anybody who has the right version.

Yes one can only make component using WD or one has to use either ActiveX or .NET DLLs. But in case of say for example ActiveX one can build one using VB6, Delphi, C++, FPC, PureBasic, PowerBasic, etc. can we make WD components using any such other languages. The answer is NO!. This openness is required. In fact just opening this up will spin up an industry of component creators.

Sure we can... that's how the ones I'm using are done... Now, I'm talking about components to use in my programs... It seems that you are talking about components to use directly in the IDE, to do I don't know what.

As I had said in my post. Try to use DexExpress's (component set name DXperience) XAF in WD and you will understand that the support for .NET components is very rudimentary. I think the reason this is so is coz WD does not implement WinForms completely internally for all types of .NET components to work properly.


It looks like this DevExpress is there to provide the functionalities that we already have in windev (like creating windows and such), but in another way...
So if you don't want to work with the windev tools, why do you want to use windev?

One of the main reason of using WinDev is that we DON'T have to buy multiple external components just to make a program. Components that will break, not be maintained, increase the price of the environment, and so on... If that's not what you want, then you should use .net instead, it's exactly how it's working.

You may be coming from another environment where you have other ways of working, but if you want to stick to those, why did you change?

Finally I will repeat that the IDE need to be opened up a bit so that we can build add-ins/plugins. What do you say about this?

We already can... In fact, in WXEDM, as you were talking about it, I'm using Francis Morel's (SoftProtect) component, written fully in windev, to protect the system from debugging tools and this is on top of an activeX to edit word documents inside a window, and a .net component to index their contents)...

Now once again, I'm not interested in replacing things in the IDE... But I can and I'm using all sorts of tools to add functions in my programs when needed.

I do agree that it would be nice to be able to integrate CODE in an easier way than with the extern keyword, so that we could generate classes and such... But that's about it, and the problem is that it would be used only by a very small proportion of the PCSoft user base, therefore it's probably very low in their priority list

Best regards

von Fabrice Harari - am 27.06.2016 11:57
Hi Yogi,
of course, we would like to be able to get at the officially unencrypted / uncompressed .wdw files and the .ana files. Both formats contain more information than is shown in the IDE. But it is not a burning need - except for being able to get at the file's generation number in the analysis. There is a function to retrieve the generation number, but only that of the physical file.

A nice addition to Wx would be to be able to have two or more analysises open at the same time. So, referencing a file would be different: Customer vs. Ana1.Customer and Ana2.Customer.

But I don't agree with your comment that you can't access third party components. With some time invested and maybe, the help of this forum or even Tech Support, you should be able to integrate many if not most third party add-ons into your program. Believe me, this isn't much easier when integrating a 3rd party component in Visual Studio except for the fact that you'd have examples there.

von GuenterP - am 28.06.2016 16:30
Quote
Fabrice Harari
It looks like this DevExpress is there to provide the functionalities that we already have in windev (like creating windows and such), but in another way...
So if you don't want to work with the windev tools, why do you want to use windev?

One of the main reason of using WinDev is that we DON'T have to buy multiple external components just to make a program. Components that will break, not be maintained, increase the price of the environment, and so on... If that's not what you want, then you should use .net instead, it's exactly how it's working.

You may be coming from another environment where you have other ways of working, but if you want to stick to those, why did you change?

It is not about why I should use WD at all and also complain. It is about opening up WD and probably taking it to greater heights.

In fact I have started linking WD to much that I want that it should actually become most used dev tool in the market. But if it stays so tightly compartmentalized it will never become one.... and never be able to attract new blood.

Take for example Xojo.
When compared to WX it is very limited but still it has more developers using it then WX products put together.
The complete (enterprise) version of Xojo is as expensive as WX. But one of the reason why this is so is because one can easily extend it, like for example adding support for third party DB servers like FireBird that are not supported directly by the original distribution of Xoja, etc.

Hope you are getting my point.

von Yogi Yang - am 29.06.2016 06:34
Quote
GuenterP
A nice addition to Wx would be to be able to have two or more analysises open at the same time. So, referencing a file would be different: Customer vs. Ana1.Customer and Ana2.Customer.

Such functionality will generally not get implemented in the original product. If there were facility to build ones own IDE add-in then one can easily solve this problem without having to wait for the original creator to build this functionality in the IDE!

von Yogi Yang - am 29.06.2016 07:36
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.