TMS Grid component don't works well!!!

TMS Grid component don't works well!!!

As you can see in the video, when I set to False the property FixedColumnResizing, the normal grid columns shall be resized clicking the mouse over the inter-cell-space of the rows that are not fixed, but not in the inter-cell-space between the cells of the header row, "because it is a FIXED ROW"

I've reported this problem to his support, but they make a curious interpretation of the situation. The statement may be like this:

"Cells of a FixedRow are considered Cells of a FixedColumn".

Agree you this interpretation or do you think this is an error?

Thank's to all for your comments.

https://youtu.be/a7L5JcyDalE

Comments

  1. the vendor defines the expected behavior, doesn't matter so much if we agree or not

    ReplyDelete
  2. Dorin Duminica
    The vendor sayed to me this "The properties are self-explanatory".
    If you want, I can remake the question, but the problem is the same.

    ReplyDelete
  3. Juan C. Cilleruelo Have you shown this video to TMS? Is the interpretation you post what they said? Sounds strange

    ReplyDelete
  4. John Kouraklis
    One similar. About the interpretation. One of the members of TMS support team has made the statistic: They sayed that to me four times.

    ReplyDelete
  5. Five times now. And he say: That this is not an error. May be a desired confusing behavior. ;)

    ReplyDelete
  6. Juan C. Cilleruelo "The properties are self-explanatory" from my experience, in Delphi, very rarely did I ever had to check some property or event's documentation, because they truly are self-explanatory.

    I get that you might be upset about something not working as you'd like, but part of a developer's job is to make things work, if you have the source code of the components, you can hack something that works for you, or, subclass, where there's a will, there's a way.

    ReplyDelete
  7. Juan C. Cilleruelo Five times? You are not a good listener.

    ReplyDelete
  8. Dorin Duminica
    In this case is not auto explanatory, because the properties speaks about "Columns" and the behavior affects, exclusively to "Cells". It's confusing!!!

    If I modify source code, I have to work again in the code, making merge of the modifications, on every update of the source code.

    Source code, that by other hand, I've payed!!!! And this is the importance of all this. If you pay for the tools, may be expected that the tools was well documented and that the tools works well. True??

    ReplyDelete
  9. Juan C. Cilleruelo My advice to you would be to use another Component Library and stop complaining here. For me the TMS Grid is working very well and I have used it for years.

    ReplyDelete
  10. Ole Harald
    The version about I'm speaking is for FMX don't confuse with the older version for VCL.

    ReplyDelete
  11. Juan C. Cilleruelo Ok, sorry. The rest of my post, still valid :)

    ReplyDelete
  12. Juan C. Cilleruelo If you pay for the tools, may be expected that the tools was well documented and that the tools works well. True??

    Looking at the delphi docwiki and the quality portal - it seems to be the delphi way :o)

    ReplyDelete
  13. Attila Kovacs: I think he is developing a FMX app

    ReplyDelete
  14. Attila Kovacs
    Basically the deploy for Mac OS X.

    ReplyDelete
  15. John Kouraklis
    Yes, of course, since Delphi XE3, I'm developing exclusively with FMX, inclusive the desktop applications.

    ReplyDelete
  16. Oliver Münzberg
    Yes. But, when you search "how to"s for delphi, you can find a lot of them. And documentations from embarcadero and others. And.... Delphi, like other libraries, have a context help that documents at design time, properties, events, methods, etc... and the hierarchy of the components.

    ReplyDelete
  17. The TMS grids are great and gruesome. I have a love/hate relationship with TAdvStringGrid. It is so complex that it is a nightmare to figure out which bits are related, unrelated or even contradictory.

    ReplyDelete
  18. Lars Fosdal
    Some resemblance to a Swiss Army knife....

    They are very powerful, but I have wondered whether it would not be best, now that they have evolved for so many years, to start over, with a clean slate.

    ReplyDelete
  19. Lars Fosdal Bill Meyer I jokingly call that "customer driven development". Customer A: "It would be nice to have X" developer adds it Customer B: "It would be nice to be able to disable X and make it Y" developer adds it ... rinse and repeat

    Having a clear and clean architecture and thoroughly thinking about changes before making them helps reducing this (not saying completely avoiding) - speaking from experience.

    ReplyDelete
  20. Stefan Glienke
    The alternative is often stagnation. Nothing wrong with responding to requests, but at some point, the bolted on chrome begins to fall off. Better then, to start over, and integrate the features in clean, rational form.

    ReplyDelete
  21. Bill Meyer "The alternative is often stagnation. Nothing wrong with responding to requests."
    Did I say that anywhere? The problem arises when implementing or changing things in a non sustainable manner but only trying to solve an immediate presented problem. Have seen that way to often and it almost every time lead (or would have) to more work or technical debt in the future.
    Starting over most of the time is not the solution unless something is completely fubar - especially not when we talk about software libraries or components that are being used.
    Guess why people wrote best sellers about how to improve bad code/architecture without completely starting over. :)

    ReplyDelete

Post a Comment