Columnwidth in tree widget.

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

When the tree widget list view column sizes are altered, it now fires an extended trigger called columnwidth. When I define the column sizes, using $fieldproperties("FIELD")="FORMATS=CL10·!CL25·!TC6·!TL17·!CL·!CL6·!TL17·!CL13·!CL25·!CL·!CL25·!CL·; LABELS=Reference·!Location·!CHS·!Due Date·!Owner·!Priority·!Date Last Amended·!Contact·!Stock Item·!Cus. Order Ref.·!Developer·!Tester" I have been using character counts. If I resize the 4th column in the tree the columnwidth trigger gets ID=3 (because 1st column is Id 0), and width=117. Does anyone have a good tip as to what one could do WITH this information to make it useful for the next time around, I'd like to store the user's preferences for column sizes and reset the column widths to those the next time, but I don't know a sane way to translate 117 (or whatever) to TL17? What do you do about part characters? Or is there a method of telling the $fieldproperties to reset the columns in pixels? If not, what's the point of this trigger? Confused

27 Comments

  1. Hi Iain, lets play the good old $uuu guessing game: perhaps the first digit defines the datatype (in this case TL17 turns to 1 for the T=time and 17 for the length). if you compare what the columnswith trigger gets if you modify the first columns or the 3rd on which seems to be a time as well, we may be able to break the code.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  2. Oh, sorry, I didn't point this out, width is the number of pixels wide, definitely. The question is more, "If proc can only set the width of a tree widget column in integer character sizes, and columnwidth is returned in pixels. How can you convert from one to the other?" or "Is there some method I don't know of to change the column width of a tree column from proc using a number of pixels." I have bodged something in using $cellinfo to get the width of a character in pixels, dividing the width parameter by that, and then setting the formats based on the integer version of that width, but :- 1. The $cellinfo documentation appears to have XSIZE for height and YSIZE for width, and the data that comes back seems to be the other way around. 2. This means the user changes his column size, and when he lets go the column gets either slightly bigger or slightly smaller (character width is 17, so it changes by up to 8 pixels because of the necessary rounding) All in all, I'd prefer a method of setting the columnwidth in pixels. I had a similar problem before when I was trying to change the depth of a text box on a multi occurrence form, when there are 6 occurrences painted, and only 2 in use, move the fields from occ 2 and make the text boxes deeper. The problem there was that $windowproperties returns pixels for the window height, and $paintedfieldproperties can only set xpos and ypos in characters (or the other way around), requiring bodging using $cellinfo, (it turns out that the values in $cellinfo do not map properly in this case and I had to apply a fudge factor to stop the fields overlapping.) I vaguely recall something being said somewhere about $paintedfieldproperties being made pixel level (was that Uniface 10?). There seems to be a lot of nasty bodging required to do anything clever in this area at the moment.


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  3. Hi Iain, to get the conversion factor from char to pixels is relatively easy: you prepare 2 forms: FORM1010 with size 10 col * 10 lines and FORM2020 with 20 col * 20 lines. for both forms, you open them up, and require the XSize and Ysize via $windowsproperties. And then calculate with the DIFFERENCE of these sizes which relates to 10 columns and 10 lines respectively. So you get the conversion Factor in horizontal and vertical direction. factorX = (Xsize(FORM2020) - Xsize(FORM1010)) / 10 factorY = (Ysize(FORM2020) - Ysize(FORM1010)) / 10


    Author: ulrich-merkel (ulrichmerkel@web.de)
  4. Hi Iain,

    FiresongKt said 1. The $cellinfo documentation appears to have XSIZE for height and YSIZE for width, and the data that comes back seems to be the other way around.

    This is incorrectly documented and I've asked that it's corrected - XSIZE is of course the width and YSIZE the height.

    FiresongKt said I had a similar problem before when I was trying to change the depth of a text box on a multi occurrence form, when there are 6 occurrences painted, and only 2 in use, move the fields from occ 2 and make the text boxes deeper. The problem there was that $windowproperties returns pixels for the window height, and $paintedfieldproperties can only set xpos and ypos in characters (or the other way around), requiring bodging using $cellinfo, (it turns out that the values in $cellinfo do not map properly in this case and I had to apply a fudge factor to stop the fields overlapping.)

    I hope you realize that $windowproperties will return the size of the "complete" window and that includes the title bar and border. In case you are using $paintedfieldproperties then you actually are interested in the size of the form canvas (this is what's inside the window borders and title bar). Currently there's no way to query the size of the canvas using a 4GL function. There are, however, ways to do this by calling the Windows API (using C Call-Out signatures). If I find some time then I'll try to dig out a little sample. Hope this helps. Kind regards, Daniel


    Author: diseli (daniel.iseli@uniface.com)
  5. All in all, I'd prefer a method of setting the columnwidth in pixels. ...... I vaguely recall something being said somewhere about $paintedfieldproperties being made pixel level (was that Uniface 10?). There seems to be a lot of nasty bodging required to do anything clever in this area at the moment.

    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  6. diseli said I hope you realize that $windowproperties will return the size of the "complete" window and that includes the title bar and border. In case you are using $paintedfieldproperties then you actually are interested in the size of the form canvas (this is what's inside the window borders and title bar). Currently there's no way to query the size of the canvas using a 4GL function. There are, however, ways to do this by calling the Windows API (using C Call-Out signatures). If I find some time then I'll try to dig out a little sample.

    I had kind of decided that must be what it was, which required some footling about guessing how big the title bar was. Also, you can't tell the size of the displayable area for a tab widget either by using $windowproperties in the tab form, or by using $paintedfieldproperties on the tab widget. (I don't think)


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  7. What if we get the option to supply pixel value's in the format property? Now it looks like: $fieldproperties("FIELD")="FORMATS=CL10·!CL25·!TC6·!TL17·!CL·!CL6·!TL17·!CL13·!CL25·!CL·!CL25·!CL·; CL; where number gets multiplied by the cell size (width) under wather to get the correct column width. If we support $fieldproperties("FIELD")="FORMATS=CL100px·!CL250px·!TC6·!TL117px·!CL·!CL60px·!TL170px; CLpx which skips the multiplication since the value is in pixels. Defined by the 'px' after the number. It looks to me that this would solve the mentioned issue's. What do you think? Jasper


    Author: Jasper (jasper.de.keijzer@compuware.com)
  8. Sounds perfect.


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  9. ulrich-merkel said you prepare 2 forms: FORM1010 with size 10 col * 10 lines and FORM2020 with 20 col * 20 lines. for both forms, you open them up, and require the XSize and Ysize via $windowsproperties. And then calculate with the DIFFERENCE of these sizes which relates to 10 columns and 10 lines respectively. So you get the conversion Factor in horizontal and vertical direction. factorX = (Xsize(FORM2020) - Xsize(FORM1010)) / 10 factorY = (Ysize(FORM2020) - Ysize(FORM1010)) / 10

    After we have the factors, we can calculate what is the overhead for Caption, titelbar, borders of a window as: OverheadX = Xsize(FORM1010) - 10*factorX OverheadY = Ysize(FORM1010) - 10*factorY


    Author: ulrich-merkel (ulrichmerkel@web.de)
  10. Because I want my window to show a range of characters. I was pushed to develop the calculations above for $windowproperties with 9.6.02. In 9.6.02, the helpfile reads: 2. Position and size is set in pixels (for example, 235 or 235px) and returned in pixels. while the 9.6.01 it was: 2. Position and size can be set in pixels (235 or 235px) or character cells (17ch). When getting the size or position, the property value is always in pixels.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  11. There was a documentation error in Uniface 9.6.01. We planned to make it possible to set the window size in character cell. But we retracted it at the last minute because it was very misleading. When setting the size of a window, you set the outer size, including frames and headers. Not the size of the canvas. So you would set the width of the window to 20ch and the canvas still would only fit something like 18.2 characters. Unfortunately we were too late in removing it from the documentation so it was removed from there in the next patch. We are sorry for the confusion this may have caused.


    Author: Theo Neeskens (tneeskens@itblockz.nl)
  12. Hi Theo, as you can see from my above formula, it is possible to calculate the overhad and add that to the equation even using just normal uniface code.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  13.  Jasper? Did you ever get anywhere with this, the same question just cropped up again here.    Regards,    Iain


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  14. Iain To answer you question about the columnwidth extended trigger, I see indeed that the tree communicates in pixels while the width is set in character cells. The easy way to handle the size is to use the $cellinfo. $cellinfo gives an associative list with the dimensions of a character cell in pixels. By deviding the width you get by the info you can store it and use it later again to setup the list view column width. I hope this helps Kind regards, Jasper de Keijzer


    Author: Jasper (jasper.de.keijzer@compuware.com)
  15. I have that solution in place at the moment, unfortunately (as per my original post) it makes the user experience jerky as the rounding inherent in the solution means that they drag the column to a width, and then it resets to the nearest whole character. Also I believe $cellinfo only relates to the font 0 character set, so what happens if I have set the tree widget up with a larger or smaller character set?  Regards,  Iain


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  16. Iain That is indeed a problem, when the font of the tree differs too much from the form font it will clearly jump. It would be nice if the property string could handle pixels by having the 'px' extension like we have on other places. I will discuss this with our 4GL guru Theo and see what we can come up with.   Jasper


    Author: Jasper (jasper.de.keijzer@compuware.com)
  17. It doesn't have even to be different, you can see the jump quite clearly if the user drags the column header, the default cell size is 17px, and an 8px jump (rounding up or down from the middle value) is pretty obvious.    Iain


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  18. Iain Sharp FYI An internal bug has been created and is submitted to the support department. I consider the columnwidth extended trigger useless when the tree-list cannot handle pixels like the grid columns can. I cannot say when or if the problem will be solved but at least it is now registrated in our bug system.   Jasper


    Author: Jasper (jasper.de.keijzer@compuware.com)
  19. Hello Jasper, this is good news. Hopefully this bug will be fixed one day. :-)


    Author: sochaz (zdenek.socha@fullsys.cz)
  20. Hi Jasper,    Was this internal bug number Issue 30511? Because the same issue has cropped up again, and I still don't have anything I can release to my customers to allow them to customise their screen layouts to fit their data that I am prepared to release.  30511 is marked that it will not be fixed. Seems a shame.    Iain


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  21. Iain Sharp said Hi Jasper,    Was this internal bug number Issue 30511? Because the same issue has cropped up again, and I still don't have anything I can release to my customers to allow them to customise their screen layouts to fit their data that I am prepared to release.  30511 is marked that it will not be fixed. Seems a shame.    Iain  

    Yes, indeed it is. Not sure why it has the status "Will not be resolved" - it probably should be "Under review" -, but as long as this bug has not been reported/escalated by one or more customers it's (unfortunately) unlikely that something will be done here. The reality is that there are many more open issues that need to be looked at and this one is currently somewhere at the bottom of the list. Daniel


    Author: diseli (daniel.iseli@uniface.com)
  22. Okay, I am going to start again, I just started writing an answer and realised that it had gotten quite agitated.  This problem is unlikely to get re-reported or escalated precisely because this forum post exists. So bringing the problem to your attention seems to be a route to make resolution more unlikely.  Unless anyone else who feels this problem SHOULD be resolved would like to take this opportunity to log a support call so as to indicate a measure of importance for it.  I appreciate that Uniface has a large workload, and that it appears to be drifting further and further away from the purpose we bought it for, and onto the web, so I suppose I should not expect much impetus on GUI problems. 


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  23. Iain Sharp said This problem is unlikely to get re-reported or escalated precisely because this forum post exists. So bringing the problem to your attention seems to be a route to make resolution more unlikely. 

    Question: have you already reported this as a call to support? There's probably some misunderstanding here, but this forum is meant for discussing issues and exchanging possible workarounds. It's not really meant for reporting problems to the lab where a fix is expected within a given time frame. It is possible that we create new bug reports, because of issues that are reported in the forum. But this is first of all for reference purposes, so that others can find this info (and possible workarounds, if available) in the known issues list. In case it's important that a problem is resolved in the foreseeable future then a call should be logged with support, along with some justification why the lab needs to spend time on this. I'm afraid that's how the support process is working. In case you are not happy with how this issue is handled then please contact your local account manager. Hope this helps. Daniel


    Author: diseli (daniel.iseli@uniface.com)
  24. I didn't think I needed to, because Jasper had agreed that the columnwidth trigger was useless in its current form and had logged the call for me.  If Jasper had logged the call due to a comment Uli or Gerton had made, and I had read this forum then I would have not bothered logging one myself because the issue was in hand.... 


    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  25. Iain Sharp said I didn't think I needed to, because Jasper had agreed that the columnwidth trigger was useless in its current form and had logged the call for me.  

    As far as I can see, no call has been logged here. And if that would have been the case, then you would have received a confirmation that a call has been opened in your name. Not sure what happened here. Confused It, however, would be a bit unusual if an engineer would open a call for a customer. That's not how the support process is working. If a customer requires a fix for a certain issue then we usually ask him to open a call with support.

    Iain Sharp said If Jasper had logged the call due to a comment Uli or Gerton had made, and I had read this forum then I would have not bothered logging one myself because the issue was in hand....

     If something is important for you then you should certainly log a call with support. Just because something has been reported does not mean that it will be fixed within the time frame that suits you (or other customers). For one customer something could be less important and he could accept if no fix is provided within a long time, but for another this could be very important and a timely solution could be vital for his operation.


    Author: diseli (daniel.iseli@uniface.com)
  26. Jasper said An internal bug has been created and is submitted to the support department. I consider the columnwidth extended trigger useless when the tree-list cannot handle pixels like the grid columns can. I cannot say when or if the problem will be solved but at least it is now registrated in our bug system.

    Author: Iain Sharp (i.sharp@pcisystems.co.uk)
  27. Iain Sharp said
    Jasper said An internal bug has been created and is submitted to the support department. I consider the columnwidth extended trigger useless when the tree-list cannot handle pixels like the grid columns can. I cannot say when or if the problem will be solved but at least it is now registrated in our bug system.
      

    As said before, I'm not aware that this has come our way. And Jasper explicitly says that he cannot say "when or if the problem will be solved". He did not say anything that this issue will be picked up and fixed within a certain time frame.


    Author: diseli (daniel.iseli@uniface.com)