dotNet

[Former Member]

Hi,

I am an experienced PB developer, started with v3, but I am struggling with dotNet.  So much does not seem to make sense.

One thing in particular is worrying me.  Let's say I create a customised commandButton, in classic I just dragged onto a surface and lo and behold we were up and running.  This does not work in dotNet - why?  Is there a workaround?

When importing an app from Classic it seemed as if it was writing any code in the control to each object that contains control, or is that just how it looks?  So if my customised commandButton contained a function of_func() and the button was used 10 times then the code in of_func() gets written out 10 times??????  Someone please tell me I am wrong.

Thanks

[Former Member · Accepted solution]

Hi Bill;

  In PB.Net its based on WPF and .... WPF does not support inheritance. So PB.Net needs to "fake" the inheritance feature internally - which it does. When PB.Net builds the C#,& XAML code for compilation it collapses all the ancestor code into the lowest descendant. Yes .. OMG ... does this not then build huge object source files ... you bet!. 

  So this is why your PB Classic code gets weird when converted to PB.net and methods look so distorted sometimes - especially when there is a significant ancestry tree invloved. PB Classic is built on proper inheritance model because its C++ based. PB.Net would also be OK inheritance wise too (pure C# only) but adding WPF into the mix basically "killed" that clean implementation.

  While WPF adds some nice GUI capabilities to your application it also breaks necessary things like getting object handles, exposing events, handling MS-Windows messages properly, pipelines, OLE, etc. So you need to think very carefully before you decide you need (want) to move to PB.Net from Classic. PB.Net not only severed things like I listed above - but, its also a one way migration. That is to say once your application is in PB.Net and you make changes to it .. you can never ever migrate it back to PB Classic.

  The other key factor for me and why I will never go to PB.Net is Appeon Web and Appeon Mobile which only works with PB Classic. Appeon automatically "bolts on" to the PB Classic IDE and then transparently allows you to work with your PB Classic application "as is". However, Appeon enables PB Classic to build & deploy JSP or ASP.net web applications, native iOS apple applications and next month - native Android applications. For my money and my clients ... its the "cats meow"! Oh yeah, Appeon also removes the PBVM dependency, makes your applications mufti-threaded, re-entrant and 64 bit compliant ... all without changing your PBL source code. It also comes in a J2EE or .Net flavour ... Mmmm yummy!  

HTH

Regards .... Chris

[Former Member · Accepted solution]

Thanks Mark and HTH.  Your comments were both very informative, although my heart sank when I read your missive HTH - NO INHERITANCE - are they having a laugh?

What I have found, though, is that import does not create XAML and without XAML you cannot drag and drop a user visual control.

But no inheritance and it's faked in PB .net, what is the world coming to?  I remember when they implemented OO in Clipper via the pre-compiler and that worked fine.  But I never thought I would use something that faked OO in 2013.

What is the rational of this?  I have now forgotten how to implement real-world applications without OO, in fact not really sure I ever knew how.

Why could SAP have not just had WPF as a presentation format but produce C# code by default.  I know C# has Java type OO, because I have used C# and it is difficult to tell the difference between it and Java.

Oh dear.

[former_member190719 · Accepted solution]

>>Why could SAP have not just had WPF as a presentation format but produce C# code by default.

That's exactly what it does.  There is no *visual* inheritance in WPF.  And that was a decision by Microsoft.  You can inherit all you want in nonvisual objects in a WPF app though.  What PowerBuilder attempts to do is provide support for visual inheritance by working around the WPF restriction.

[Former Member · Accepted solution]

I see Bruce,  I suppose the use of WPF meant that the C# produced was simpler and there was less of it.

It all makes sense now.  The only real issue I have now is that some very strange errors occur, for example if you migrate a screen containing memo fields and they have tab stops set, then this causes some very funny results.  Now many apps will use memo field and I guess tab stops are set by default, so not a great start.

I was getting an error where it was telling me I should use type of pb.int but not where the error was.  I kept commenting out code but the error stuck around, again not a great start.

Not sure what to do now.

[Former Member · Accepted solution]

The lack of documentation is becoming a pain.  I use properties a lot in PB, for example If I am developing a visual object (a dw descendant say)  I can declare an instance variable, lets say [boolean ib_sort] and then when I use this object in, say a window, I can then tick on ib_sort.  The advantage with this is that ib_sort gets a value from the checkbox before the constructor is called.  So I can use the value of ib_sort to initialise a Sort service in the Constructor.

Now the .net version allows you to declare properties and I have tried this but I cannot find whereabouts you see them, ie to set or unset.  A decent bit of documentation would help.

btw if anyone knows the answer please let me know.

[Former Member · Accepted solution]

Hi Bill;

  Yep ... my whole free STD Foundation Classes framework library (http://sourceforge.net/projects/stdfndclass) for PB, EAServer, IIs & Appeon is all based on this type of design! That is exposing "protected" variables in lower level descendants where the developer just needs to fill in or change a value to make it work. That is so much easier than the archaic way the PFC does things. The handling of "protected" variables is just one of the key reasons that I stay with PB Classic for all my framework development. I only "port" a copy of my PB Classic code to PB.net whenever I absolutely need to. I mentioned this "Protected" property oversight to Sybase way back in PB.net 12 beta 1 - but (as unusual) was just ignored.  

Regards ... Chris

[Former Member · Accepted solution]

Like you I have developed a 'framework' over the years.  I remember when pfc first emerged and being quite excited, until I looked at some of the sample apps that used pfc.

My first impression was how ugly it all looked - yes I know this is an aesthetic but.......

My second impression was that it took so much effort to setup for a new app.  Even then my own fledgling framework was doing a much better job.  I think the major design flaw in pfc was in trying to do the whole thing.  My framework always had much narrower goals, one of which to was to cater to my inherent laziness.

In my framework I inherit from some base type and a whole series of extra properties are visible in the properties window - ie uncovering protected instance variables from the ancestor.  I then drop controls onto the surface and the same thing occurs again.  No coding but the object is already taking shape.

I am amazed at times when I see how little code I have had to write for a window to become fully functional.

[Former Member · Accepted solution]

Yep .. that is how my framework works as well and ... the initial design for that & construction started in 1992. There is nothing like the old KISS principle I say!

  The other thing that killed the PFC was the fact that it was only for fat PB client applications. It was never rewritten to accommodate n-tier, web and of course now Mobile computing. However, my framework still keeps evolving every 3-6 months to match the rest of the IT world that keeps on changing every year as well.  

[Former Member · Accepted solution]

Hey Bill,

You can look in the PowerBuilder .NET Features Guide help for the topic "Defining .NET Properties". It describes how to declare, set, and get the properties and their values. I would fire up PB and try to give you a good example but SySam is screwed up again. I think it has done more harm to PB than SAP ever did but I digress.

A typical getter script (with no extra logic) would look like this:

return [your property name]

A typical setter (with no extra logic would) look like this:

[your variable name] = value

Set its scope based on your need.

I'm guessing you tried the instance variable route as you described and it didn't work for you. That surprises me.

hth,

Mark

[Former Member · Accepted solution]

Hi Mark, I expected to see protected variables appear in one of the properties windows, as it does in Classic.  I had in fact correctly designed a property but hadn't realised it.

I used C# some years ago and it all came back to me about properties in this environment.  The only advantage I can see using properties in this case is that you can add extra coding in the set or get, it doesn't (I think) offer any more protection.

[Former Member · Accepted solution]

Properties are a nice feature I think.

Unlike protected variables they are not necessarily mapped to variables, they can also be read-only or write-only.

In Pb classic, you can do almost the same with keywords like PrivateWrite, PrivateRead or Indirect, which makes properties not so useful for a Pb developer, but these keywords don't exist in C#.

And it was a constraint to be .NET compliant, so they had to add them.

[former_member190719 · Accepted solution]

The other thing that killed the PFC was the fact that it was only for fat PB client applications.

I was unaware that PFC was dead.  If anything, the download stats for the project tell a different story.  In fact, I believe the total downloads of PFC since it was moved to CodePlex exceed those that you indicated earlier for your own framework, and that doens't include the stats from it's previous hosting on CodeXchagne.  Pretty spry if you ask me for being "killed".

 It was never rewritten to accommodate n-tier, web and of course now Mobile computing.

You say that, but then you also indicated in another thread that:

Most PB developers use and still plan to use PB Classic (aka NATIVE). In fact its 90% plus for PB Classic!

If that is the cae, PFC is covering 90% of the base use.

. 

[Former Member · Accepted solution]

CodePlex ....

PFC12.5  source code, 5090K, uploaded Apr 30 - 565 downloads.

=> I have over 800+ downloads for my current release since April. And that does not count my EAServer, IIS or Appeon flavours of the framework either. (over 7,000+ downlaods this year all up)  

Yes, the PFC & my Framework download numbers though do accentuate the fact that PB.Net is a "Non-Starter" compared to PB Classic. 

[Former Member]

I think I have answered my own question - it happened while I was laying in bed this morning.

If I import (nb NOT migrate) a visual object then it does not create the XAML for that vo - correct?

In my original question I meant to say "When migrating an app..." not importing, but I think it does do it correctly.  It is just that XAML does not show it as the visual object you created but as the base type, in this case CommandButton - which I was not expecting.

Also surprising was the following:

i     I created two windows and dropped an instance of u_cb_root onto the surface of each - fine everything looked OK.

ii    I changed the button text on each window to "1" & "2" - ie they showed different button texts as hoped for.

But if I looked into the 'Source Code Text Editor' neither of the source code of the 2 windows showed that the button text had been changed.  This was shown in the accompanying window XAML only.

Making progress but I would welcome any help & tips from you guys who have been using PB dotNet for a while.  For one thing, where is the documentation?  I have the dotNet features guide and the deployment guide but these seem to be missing a load of stuff about the IDE.

[Former Member]

Hi Bill,

I can't help with the import/ migrate question as I don't have my PB VM running at the moment.

As for documentation the only thing I can offer is their online documentation: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc01261.1250/doc/html/title...

If it's not there it probably doesn't exist.

Also Bruce Armstrong has spent countless hours creating several informative videos regarding PB.Net. You can find them in lots of places: his blog, powerbuildertv, youtube, this site, and others.

Thedisplacedguy also has some videos too.

If you have specific questions about the IDE post them here and someone will probably be able to help you.

Good luck!

Mark

[Former Member]

I have now spent a couple of days working with 12.5 .net and here are my conclusions:

(a)     Well it will actually run some code.

(b)     The IDE is an absolute pain to use.  I think the problem is that you have XAML code and PB source code and these have to be in sync.  Unfortunately the IDE just isn't clever enough to always keep them in sync.  So you have to edit the XAML (eg remove a control) and then remove it from the source code.  Or, does someone know a way to form XAML from source code?  I cannot see any obvious way, but you never know.

(c)     The IDE is much worse with custom objects or simple extended objects, it will not let me rename them.  As an example, I wrote an OK/Cancel object.  This is a very simple custom object with 2 buttons on its surface.  When I dropped it onto a window it named it uo_1 and would not let me change this name.  In fact it eventually told me I was trying to add an object with a duplicate name.  Simply appalling.

Have any of you spent much time with it?  Are your experiences better, worse or the same as mine?  I would like to know.

[Former Member]

Hi Bill,

The IDE is a bit painful and heavy to use but introduces some nice features too, like Intellisense, tabs, multi-screen support, global replace and other things I don't remember now.

I have no problem for changing an object name on a window, but you're right about the properties, they are not shown in the IDE like they should, I guess there is some underlying C# missing to make it work.

We spend some time on Pb.Net and basically it gave us the feeling to not be finished, we estimated that it was to much work and too much risk at this time :

1) Many things to rewrite (ole stuff, web services, pbdom, api calls using Handle function) and like Chris said, it's a one way migration.

2) No visibility on what it will become, we thought at first that it was the future of Pb but that's far from certain right now, no news from SAP, the unofficial roadmap we seen let us think SAP will focus more on classic (if they release something) and we're not really sure about WPF sustainability.

3) We have learned to do modern interfaces with Pb Classic, we have to code a lot by ourselves but we're used to. We achieved almost the same look & feel than our WPF co-workers. Gradient and transparency are our best friends.

Regards

Guillaume

[Former Member]

I think agree about 100% with you there Guillaume apart from the changing an object name problem.  If I drop an object (inherited from a SLE) onto a Window (inherited from my root window) then I cannot change the name from sle_1 to anything else (eg sle_id in this case).  The only way I could do this was to do a search and replace in the source code.  Open the object in the normal fashion in the IDE, it wasn't too happy at this point, and then change sle_1 to sle_id in the XAML window.  Not a great solution.  Is this something to do with inheritance (or lack of) in WPF?

The thing I agree with you most about is your point about it not looking like a finished product.  The IDE is worse then PB classic v7, which was awful.  Funny thing about ver7 was that production code was pretty much rock solid.  Still in ver 12 (and ver10) classic we seem to have a rock solid IDE too.

WPF sustainability?  There are rumours on the new that WPF is perhaps coming to end of life, so maybe SAP will drop this pathway and concentrate with classic, as you say.  At least they are in control then.

[Former Member]

Hi Bill;

   Amen brother .. well said!   FWIW: Now that David Avera (Mr DataWindow) and Reed Shilts (Mr. PB.Net IDE) [best PB engineer out there IMHO] are no longer working on PowerBuilder (David on another product and Reed was let go by SAP) - I don't see any fixes to PB.Net coming in the near future in my crystal ball.

  As for WPF .. I have been saying that MS is phasing WPF out for the past 1.5 years but no one believes me. Not one Canadian Government project is using WPF (hello!) and my friends in development at MS are now saying that the WPF team is being significantly downsized ... so I think you are correct - the writing is on the wall for WPF.

Regards ... Chris

[former_member190719]

I'm not a huge fan of the WPF target.  After a lot of work to do a migration, what you end up is what you started with, a desktop application.  I believe the intent of the target was two fold:

1.  Provide customers with the capability to do much more modern looking applications, which they had been clamoring for.

2.  Transition to WPF, which at the time seemed the direction that Microsoft was headed for with Windows desktop applications.

In the end, most customers seem to have decided that they could get the modern looking features without having to go to WPF, or that the move to WPF wasn't worth the improved interface.  And in the meantime Microsoft has since veered off in a different direction with regard to Windows desktop applications.

However, I do find a number of the other target types quite useful.  You might take a look at them:

1.  .Net assembly (including the ability to create visual assemblies that can be used by other .Net tools)  http://www.youtube.com/watch?v=Qxpaytqk66Q

2.  WCF web service.  http://www.youtube.com/watch?v=MT2C-HL58d4

3.  WCF client  http://www.youtube.com/watch?v=ez-H3uzQHYw

4.  REST client.  http://www.youtube.com/watch?v=vNR8B8nelTg

The clients created by the last two projects can be incorporated into PowerBuilder Classic applications though a COM Callable Wrapper:  http://www.youtube.com/watch?v=FKVxi1CFG2w

[Former Member]

Hi Bruce;

   IMHO, I think that the prudent thing for SAP to do now is put the WCF/REST targets into PB Classic and move forward using Classic from there for the PB Community's  sake.  

Regards ... Chris