Well... You are missing something. They are not using the isollated shell. otherwise we should install it somehow. This doesn't happen during installation. They use actipro (as you noticed) wpf controls... No vs isollated shell, no ICSharp shell (I don't see avalon libs), no vs plugin e.t.c. Simply those actipro controls, which for a very logical price and license terms provide all they need to create this ide.
This proves that WPF can really facilitate a developers life, if they know what they want to do, and of course if they know how! You may be right that wpf are dead... Your Canadian government chooses web application because those can fit their needs, not because wpf are bad implemented. And if they rejected wpf for windows applications it may be because of us (all developers who do not have a deep knowledge of that "technology"). In my opinion wpf is so close to what java does with javafx. (Actually I believe wpf are better than javafx!). But java was free for a long time, and of course it's cross platform... VS became free right now, and not for everyone! Our Greek government seems to be on the java way (should I believe that .net is dead because of that?)...
In b4x they use actipro's skin control to create skins, which lot of people request for pb IDE and their applications (although skins are available in pb.net)... So this is easily done in wpf. Also in b4x they use actipro's: docking control, syntax editor control, navigation & editor controls. They use only two components from ICSharpCode, the treeview and the zip library (through .net framework has native support for zip archives). Of course they are dependent to windows platform, that's why they don't provide versions of the IDE for other os...
What I wanna say is, that because the wpf implementation in pb was bad, or because pb.net was bad, this doesn't mean at all that those solutions are bad... The implementation was bad! The implementation was so bad at first time (pb.net v. 12), they tried to arrange things in later version (pb.net 12.5) but a bad implementation which has been "fixed" may be still worst than a good implementation!!! And that's what I believe Sybase did wrong. They tried to fix something that was designed wrong in the first time! In some points the result was really better, but compared to competition it was still average to bad. As for the wpf targets, the inheritance of all those controls to a runtime should not be implemented that way, because it was making us need to deploy additional runtime... Only Datawindow & transaction object and other objects specific to PB should be provided as a runtime... The rest (windows, buttons, tabs, checkbox's e.t.c.) which are available in wpf.net should be provided like "PFC's" does -> as an inheritance of those base .net objects in source code with some additional implementation - properties e.t.c.!!! Anyone who buy pb doesn't buy the product for those controls,,, they buy it for datawindow, datastore, pipeline e.t.c.
Having the source code of changes between base window class to pb level window class, should not be a problem. This would make the required runtime libs less than now, and many things could work with a dependance only to the framework...
Now the way Appeon is looking things, is a better way... The whole plugin idea is a good one, but only if pb should be tied only with .net... If we want it to be also tied to java, I think there will be a lot of problems! And of course all this is still in discussions. We don't have any implementation - protoype in hand...
Finally I'm open to hear other people opinions... Especially in WPF. But please do not tell me if they are alive or dead... Tell me first of all your experience in vs & wpf... Because I believe it may not be the success MS was expecting but they are not dead at all. And I believe we use wpf applications, without knowing it's wpf, as with b4j and b4a... And Erel is not a stupid guy to make an investment to a technology that's dead especially if you take a look when those products (b4x) were launched...
Not saying WPF must remain in PB (but I use them and yes there are lot of times I do things easier than in pb classic, thanks to .net).
Finally, Chris, I may disagree with some of your opinions about PB's future, but it's always a great pleasure to read your opinion and to have this exchange of Ideas... Hope it will also help Appeon to provide a better PB product... And at this point I will agree with you that PB needs to provide a way to deploy applications to the WEB... Somehow nativelly... And of course Win32 targets must remain, as most of existing app's are there. But we need an IDE wich will have the database features (database management, datawindow designer, pipeline designer e.t.c. from classic, with all good stuff from VS Shell in the code editor) as many have stated (included you). Also I prefer the way pbl's work in pb.net, but I wonder what would be the impact for win32 targets to go to such a logic...
Andreas.
Chris Pollach wrote:
Hi Andreas;
Yes, I believe that they use Actipro controls. What I do not know - but suspect - is that they use the VS Isolated Shell vs a VS plug-in approach. My guess is the Isolated shell as their IDE GUI does not look like your standard VS interface (like PB.Net used) - yet, has the tell tail VS signs.
If Appeon wanted to use the VS Isolated shell - that would also be OK with me. Just get rid of WPF (pretty much a dead end for application development here in the Canadian Government) and return back to the Win32/64 world. From Armeen's preservation though, I get the feeling that Appeon is considering a plug-in approach to VS. If that is the case (hopefully, Armeen will expand on that on Dec 8th), the plug-in route does provide a much deeper .Net connectivity aspect than using the Isolated shell which does not expose all the .Net feature set.
Personally, I don't really care about whether Appeon uses its own IDE, Eclipse, VS, etc as long as I have clean & easy to use Inter-ops to .Net and preferably Java as well. Really all the PB Classic IDE needs is the collapsing code block feature and intellisense. The key question for Appeon to answer is whether wasting a lot of time trying to move PB Classic to another IDE (like PB.Net did) vs just adding a few enhancements like I just mentioned to PB Classic IDE a better ROI.
Now for a new futuristic PB product (if that is the Appeon vision's case) - then basing this on a standard commercially or open source IDE makes more sense. Creating a new PB from the ground up would allow Appeon to build the next generation using a technically advanced platform. In that case, you optimize your ROI for a new product by capitalizing on an existing and known IDE that provides all the plumbing for your new application venture right from the starting gate.
It seems to me there are two paths here. One for the current PB Classic customers to continue with an enhanced PB Classic to allow them to move their current PB applications forward and the second path where a new PB generation product allows new applications and a whole new developer generation to experience a totally different way of developing but maybe with some of the things we love today in PB Classic like the DataWindow.
Regards ... Chris