doit: false on endEdit callback...

[sharma.narender]

If I execute the code "doit: false" in the endEdit callback, I expect that focus/cursor/selection will remain on the current cell being edited. However as per current smalltalk(ver 7.5) behavior, selection reamins on the other cell you just clicked on while the cursor is back at the current cell being edited. Please note that table has XmCELLSINGLESELECT policy.

I think this is a bug.... can someone from Instantiations look into this ?

bug.png (5.09 KiB) Viewed 669 times

Steps to replicate...
1. Click on the cell containing the value 2.
2. Click on the cell containing the value 1. Now end edit callback for cell having value 2 will get fired and the code is such that if the value is 2 we set "callData doit:false". My expected result is that cursor as well selection should return to cell with value 2, however the selection is still with cell with value 1.
3. Now click on cell with value 4. My expected result is similar to #2 above.

Thanks in advance!

[tc]

Hello,

Thanks for the testcase. I was able to reproduce the problem.

I opened Case #47905 for this issue.

--tc

[sharma.narender]

Hello,

Thanks for the testcase. I was able to reproduce the problem.

I opened Case #47905 for this issue.

--tc

Thanks for looking into the problem. Any timeline for its resolution ?

[sharma.narender]

Hello,

Thanks for the testcase. I was able to reproduce the problem.

I opened Case #47905 for this issue.

--tc

Thanks for looking into the problem. Any timeline for its resolution ?

Thanks for looking into the problem. Any timeline for its resolution ? Would you be able to give response if I send a mail at vast-support@instantiations.com with all the details from this discussion ?

[tc]

Hello,

I do not have a timeline. Another team member took the case and I'm sure she'll post any news she has.

--tc

[tc]

Hello,

I looked at this since the other person is busy. At IBM, we used the same technique of checking values in the endEdit callback and I do not recall having this issue but I'm pretty sure we used a different table.

For this table, I noticed the methods are about 14 years old and a rewrite might be hard since everyone's approval is needed and we've not seen this issue come up before.

However, the effect you are looking for is easily achieved as follows:

Code: Select all

endEdit: aWidget clientData: clientData callData: callData

   (callData newValue = '2')
      ifTrue: [
         callData doit: false.
         aWidget highlightedCells copy do: [ :aCell | aWidget unhighlightCell: aCell commit: false ].
         ]

. . . this change keeps the focus at the cell with the wrong value and makes sure no other cells are highlighted until the proper value is entered.

--tc

[sharma.narender]

Hello,

I looked at this since the other person is busy. At IBM, we used the same technique of checking values in the endEdit callback and I do not recall having this issue but I'm pretty sure we used a different table.

For this table, I noticed the methods are about 14 years old and a rewrite might be hard since everyone's approval is needed and we've not seen this issue come up before.

However, the effect you are looking for is easily achieved as follows:

Code: Select all

endEdit: aWidget clientData: clientData callData: callData

   (callData newValue = '2')
      ifTrue: [
         callData doit: false.
         aWidget highlightedCells copy do: [ :aCell | aWidget unhighlightCell: aCell commit: false ].
         ]

. . . this change keeps the focus at the cell with the wrong value and makes sure no other cells are highlighted until the proper value is entered.

--tc

Hi,
Thanks for replying and suggesting the alternate approach. Our project team deliberately did not take this approach, since unhighlightCell: commit: is a private method... Is it a good practice to call the private methods of the other class in the Smalltalk code, just because of the fact that Smalltalk has not enforced access rules ?

Thanks!

[marten]

No, it is not a good practice - but all decisions can be justified. And consider the fact, that the image is yours - you are allowed to do anything you want. You may even modify the applications delivered from Instantiations. That is also the strength of Smalltalk.

Of course - changing the application from Instantiations may produce additional support problems - when new releases are coming.

Hi,
Thanks for replying and suggesting the alternate approach. Our project team deliberately did not take this approach, since unhighlightCell: commit: is a private method... Is it a good practice to call the private methods of the other class in the Smalltalk code, just because of the fact that Smalltalk has not enforced access rules ?

Thanks!

[tc]

Hello,

That method is 14 years old and it is the only one that can do the job needed. Looking at it, I would not consider it to be low level.

The VA Help guide says:

A popular convention is to make a method public if other parts (or classes) use it, and make it private if only the class that contains it uses it.

. . . that is why it is private.

--tc

[a62754]

The method has a commit parameter and manipulates the selected items collection based on this parameter. This method is very tightly coupled with the rest of the functionality of this class. Can/should only be used if you have knowledge about the whole workflow. This can put your UI in an invalid state if not used in correct conjuction with the rest of the highlighting/selection functionality. Because of these reasons this method, i feel, should be treated as private and not used publically.
So, till the time you get a fix from VAST, use it only if its necessary.

[sharma.narender]

Hello,

I looked at this since the other person is busy. At IBM, we used the same technique of checking values in the endEdit callback and I do not recall having this issue but I'm pretty sure we used a different table.

For this table, I noticed the methods are about 14 years old and a rewrite might be hard since everyone's approval is needed and we've not seen this issue come up before.

However, the effect you are looking for is easily achieved as follows:

Code: Select all

endEdit: aWidget clientData: clientData callData: callData

   (callData newValue = '2')
      ifTrue: [
         callData doit: false.
         aWidget highlightedCells copy do: [ :aCell | aWidget unhighlightCell: aCell commit: false ].
         ]

. . . this change keeps the focus at the cell with the wrong value and makes sure no other cells are highlighted until the proper value is entered.

--tc

The code suggested above would leave the UI in invalid state. Per smalltalk a cell being edited is also the selected cell. If i execute the above code it will clear the edit cell from the selected cells list. I have got it working right though.

... This is the reason why we should not use private methods. Since now we have to be responsible for doing everything right, rather than the API.

Thanks everyone...

[a62754]

TC - your workaround isn't working as expected. Do you have an Instantiations approved workaround till the case is open?

[tc]

Hello,

Try this:

Code: Select all

EwTableList>>#verifyCellSelectionProceed
"See if cell selection processing
should continue.  Answer true
if selection can continue, false
if it cannot."

   self canCellSelectionProceed ifTrue: [^true].

   "Unhighlight any other cells."
   self highlightedCells copy do: [ :aCell | self unhighlightCell: aCell commit: false ].
   self
      cursorCell: self editCell forceFullyVisible: false;
      highlightCell: self editCell commit: false.

   self highlightedCells: self selectedCells.
   ^false

. . . an 'approved' change means everyone has signed off on it. One person, who is on vacation, told me she did not think this method of error checking was valid. I feel it is because we used it at IBM but I may have been working in modified base code.

Issues like that will have to be hammered out internally when people are back. Meanwhile, it would help a lot if you can try the above change and post your feedback.

Thanks.

--tc

[solveig]

Hello, Mr. Sharma,

Could you please send e-mail to vast-support@instantiations.com? I would like to discuss with you the example you sent and the behavior of the control. Generally when examples are provided, we take discussion off line and post the results. This is what I would like to do in this case. I await your reply on our support line.

Regards,
Solveig

[sharma.narender]

Sent mail.

Thanks!

Hello, Mr. Sharma,

Could you please send e-mail to vast-support@instantiations.com? I would like to discuss with you the example you sent and the behavior of the control. Generally when examples are provided, we take discussion off line and post the results. This is what I would like to do in this case. I await your reply on our support line.

Regards,
Solveig