1. Glenn Barber
  2. PowerBuilder
  3. Tuesday, 22 October 2019 19:50 PM UTC

We have a powerbuilder application where we use forms which display text fields which have autosize height.

These fields are stacked on the form vertically one above the other.

An average sized height is provided in the form, but if more text or data is entered than provided, the autosize feature makes the field taller.

As the fields below are set to reposition (slide up), there is no problem with the display of fields below.

However, there is a long term PB bug which has never been addressed, where the cursor position of the repositioned columns below is not updated, so clicked events on them don't fire properly.

We reported this problem long ago and were told it likely wouldn't be addressed in current maintenance releases.

Is there a getaround for this - so we can use stacked auto resize fields that need to be supported by a clicked or doubleclicked to pop up the appropriate editor?

 

 

Roland Smith Accepted Answer Pending Moderation
  1. Tuesday, 22 October 2019 20:24 PM UTC
  2. PowerBuilder
  3. # 1

What version? Long time ago to whom (Appeon, SAP, Sybase)?

 

Comment
  1. Glenn Barber
  2. Tuesday, 22 October 2019 22:11 PM UTC
I responded in the thread...rather than a comment - not sure how these get out of sequence.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 22 October 2019 20:41 PM UTC
  2. PowerBuilder
  3. # 2

Hi Glenn;

   FWIW: AutoSize Height and AutoSize Width features were added to PB for reporting purposes only (in the good old PowerSoft days). No columns or computed fields were ever meant to get focus when using "AutoSize xxxxx". In other words, everything in that type of DWO should be set to "Read Only" (aka Tab Positions = Zero). Thus, no cursor position would be possible.

  FYI: You could try using the ObjectAtPointer() command and see what happens.

Regards ... Chris

 

Comment
  1. Glenn Barber
  2. Tuesday, 22 October 2019 21:21 PM UTC
Yes - we might see if when we trap a clicked event if it will help us identify which object. We may have tried this a long time ago, and perhaps found that this function was also not working properly either - as we can't rely on actually clicking an object - we would have to trapped the clicked event in the datawindow, then see if the location was actually pointing to an object.
  1. Helpful
There are no comments made yet.
Glenn Barber Accepted Answer Pending Moderation
  1. Tuesday, 22 October 2019 20:53 PM UTC
  2. PowerBuilder
  3. # 3

Hi Roland - This exists in the current 2017 build and has existed as a problem under 12.6 and much much earlier.

I reported this to SAP , nothing happened with it.

I reported this to Appeon in early 2017 when they had just started taking over support of the product and spoke with Armeen about it and similar datawindow issues.  I wrote up the details to the the Appeon PB Product Manager in early March of 2017.

There are numerous design flaws with datawindows that inhibit the creation of modern looking applications - among them no In field prompts, lack of Null Support for Dropdowns, graphical support for border types in column labels that match column 3d lowered style, dynamic (as you type) field resizing, etc...

My understanding was that some of these were going to be addressed in the future, but not in the 2017 Long Term Maintenance release.

Most of these can be accommodated by somewhat tedious coding - if not perfectly, however this issue with the system losing track of cursor position for trapping clicked on repositioned objects is a particular PITA for us.

 

 

Comment
  1. Glenn Barber
  2. Tuesday, 22 October 2019 22:09 PM UTC
HI Michael - can you provide a bit more info about in-field placeholders and how they work? I seem to have a problem locating anything relevant in the on-line docs.
  1. Helpful
  1. Roland Smith
  2. Wednesday, 23 October 2019 01:13 AM UTC
If you want to really advance your desktop GUI, I have a free control that allows you to code the user interface using HTML. It is a PBNI visual extension that implements an HTML control called Sciter. The main downside is that it doesn't support Javascript. It has its own language that is similar.

Check the very bottom of this page for 'PBHtml':

http://www.topwizprogramming.com/tools.html

  1. Helpful
  1. Glenn Barber
  2. Wednesday, 23 October 2019 20:17 PM UTC
Hi Roland

Ideally, having windows, datawindows, etc supported in a local HTML is a great idea for modernizing. I would indeed be surprised if we don't see something like this in the next generation of PB with something like typescript. We are super busy right now, but I will certainly like to come back and take a look at this.

Thanks
  1. Helpful
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Tuesday, 22 October 2019 21:03 PM UTC
  2. PowerBuilder
  3. # 4

Have you tried DataWindow control's GetObjectAtPointer( ) returning string = object + TAB + row?

I picked below from a "fluent API" DW class I use in demo apps. 

HTH /Michael

// PUBLIC FUNCTION GetCurrentRowObject( REF long row, REF string name ): dw_base
long   tabPos
string objectRow

objectRow = this.GetObjectAtPointer( )
tabPos    = Pos(objectRow, '~t')

row = Long(Mid(objectRow, (tabPos + 1))
name  =   Left(objectRow, (tabPos - 1))
return this // Fluent API
Comment
  1. Glenn Barber
  2. Tuesday, 22 October 2019 21:15 PM UTC
The problem is that the user is clicking on the object and we are expecting the clicked event for the visible item to activate. However, depending on where you click, nothing might happen or you might get the response for a different object that was located in that position before everything moved.

Ideally the getaround would be to somehow capture the new boxed coordinates of repositioned objects - then we could use the coordinates of the pointer to figure out which objects clicked event should be fired.
  1. Helpful
  1. Michael Kramer
  2. Tuesday, 22 October 2019 22:02 PM UTC
That's why I was curious whether GetObjectAtPointer actually picked the re-positioned control within the re-positioned coordinates despite the Clicked event looking at the "original" coordinates. I'm using multi-object slide up in an edit-enabled DataWindow - but I positioned the edit-enabled items at top of detail band so they don't move. Only display-only items and labels have dynamic position. So I avoid the complexity that you need to solve.

(I'm lucky, took over an app where previous developers never used (never knew?) slide up/left)
  1. Helpful
  1. Glenn Barber
  2. Tuesday, 22 October 2019 23:08 PM UTC
I will give this a shot later and see what I end up with. We may have tried this before however...
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.