Here in Massachusetts all non essential business have just been are shut down, and I suspect it will last long past the date the governor said (April 7th), so I may have a lot of time on my hand (and if my company does not make its through I may have a LOT more time… Getting another job at almost 65 would be hard!)
I originally wrote it when I was laid off during the ‘Great Recession’ about 10 years ago (I got another job in my field right after I finished it).
Since then I have only only had to make a few minor updates over the years to keep it working. That was being true a big plus for my keeping using Xojo …
Anyway besides merging cells, I added some functionality, some of which Xojo inc has since added to the listbox, but of course with a different API than I created … and I never updated it for dark mode or retina.
Back when I wrote it , it was the only listbox available fro Xojo that allowed merging across both rows and columns… Today there are other listbox options that are not subclasses of the Xojo Listbox and so are not limited by that approach.
I never had a lot of sales - not sure if I even made minimum wage for the time I put in to create it (though I never really pushed it) . I always said to myself if I went a full year with no sales I would open source it. Last year was ALMOST the year, but then I had one sale in December!
Right now I have no need to redo it for myself, and modernizing it, making it’s API consistent with the changes Xojo has made over the years, never mind updating it for API 2, and redoing the documentation (which was not great to begin with) would not be trivial.
I am wondering if there might be enough demand for it to be worth my time - that is would there be any demand at all for it… or maybe my time would be better spent doing something else…
I had never even heard of it but it looks really nice. I assume this is the link to it? I have to say that I wouldn’t pay $125 for it - that seems steep. I totally understand how much work these controls are but the 3rd party market is odd in the Xojo world. I spent 2 months writing MarkdownKit and in the end gave it away for free because nobody would pay for it even though it’s been very well received.
As I said besides occasionally mentioning it on the forum I never pushed it.
I agree that seems expensive to those of us not earning a living with Xojo…
Initially I also had a cheaper encrypted version (IIRC $39 US) but the only sales I got were for the $125 source code version as most of the sales were to pros for whom time is money.
After a while i saw no point to bother with the licensing code hassles needed for selling an encrypted version no one was buying.
Anyway that makes me think that if I dropped the price to $39 for the source code version, it would make no difference to sales. If there would be decent sales at that price though it would be worth spending the time to up date it.
I guess it in part comes down to whether or not you’d enjoy rewriting it? If you’ve got time on your hands it could be a good opportunity to really dive into API 2.0 for instance or revisit parts of the code to see if you can refactor it / improve it second time round.
odd is one word for it
Xojo doesnt promote third party items very well - even when they are the only way to do something really well. So third party items are largely invisible.
And, because a lot of people are what many might term “hobbyists”, they dont tend to pay for add ons.
Anyone writing software for their job may, or may not, really depending on whether they have to pay for things out of pocket or not.
Parts of it were, but most of it was slogging through details of the Xojo listbox behavior empirically so I could match it, and implementing the changes under the hood in way that enabled presenting the expected listbox API (well the one from 10 years ago) and trying to make the API for new functionality work analogously so that it blended somewhat intuitively with the rest of the listbox API.
For it’s day it supplied a lot of functionality that IMO was reasonably competitive with the other 3rd party options available (and I wish I had had more confidence to push it back then!) … I’m not sure that is true now.
If I am going to keep using Xojo I guess i would need to start using API 2
I’m sure I could, and I would need to, to make it completely compatible with the current Xojo Listbox API (how they handle indent level now is different from how I did for example)
unless they break the classic api why ?
since it is a subclass you can define whatever events you want
you arent required to be compatible with any of their API IF you implement every event and then do whatever you want
the hard part is that this might mean having 2 versions since in versions < 2019r2 there is one set of events and in newer version there are newer and different ones and you cant dynamically add and remove event defs and event the event handlers adequately
What I thought would be a big selling point was keeping the API the same as Xojo’s as much as possible, to make using it easier. Using my own unique API just makes a steeper learning curve for end users…
But given the current situation it would mean creating two versions as newer Xojo users will likely be all API 2 and a fair number of old timers would still be API 1… Though maybe those that might buy would tend to be newer users? If so the only an API 2 version would make sense…
API 2 sure complicates the Xojo world!
Anyway i still don’t know if it’s worth doing… it would definitely feel more like work than play… and I like to get paid for work!
Oh sure I get that
But you’re not compelled to follow api 1 or 2 if you implement every event handler and then define your own
that task just got worse with versions > 2019r2
Anyway i still don’t know if it’s worth doing… it would definitely feel more like work than play… and I like to get paid for work!
agreed …
dunno if the trick here is that for many tasks the basic listbox is mostly adequate
and only where you get some really special needs do you need to move to something like yours
I know for what I’m working on thats about where we are today
that could change but we’ll see
I’d say the vast majority of Xojo users are hobby and citizen developer users who as you know are price conscious, so there the perception is “Nice, but not value for money when comparing to Einhugur or MBS”.
With sales down to 1 per year you might consider inclusion in the next OmegaBundle … if they sell a thousand bundles and you get $10 or $20 per sale then I guess that blows your previous sales income out of the water.
The price sensitivity was why I did the $39 encrypted version initially, but as I said I had no takers.
Before including it in something Like an OmergaBundle I would need to update it and make sure the new code is throughly debugged, as if I keep my job i would not have a lot of time to do a lot of support for less knowledge users (you still need to know the Xojo listbox to get the most out of it… and many seem not to bother with that).
Norm is right.
If you know the Xojo listbox well you can do a lot without too much effort for a particular case. Most of the work I did had to do with being able to handle just about ANY use case.
The core functionality is not that difficult to duplicate for many specific cases. I banged out a proof of concept very quickly way back when… Making it general with a general purpose API was where most of the work was.
I would think even the old version would be a useful addition to a bundle as it shows users HOW they can do it.
But nowadays you are competing for example with Jim’s solution that can do so much more (and ListBox replacement is just an added benefit to it). I think that is also the reason why Björn never wrote a replacement for his Grid.
Which is why I suggest the bundle. It might still be useful for users of older Xojo versions at least, it’s useful as a learning tool, and you’ll possibly get enough money for one of the new Mac Pro out of it. Win-Win-Win situation as far as can see. Just make sure it’s well documented.
And if you DO decide to make a new version (maybe initially for yourself) then you can offer it as a paid upgrade.
The hard thing now with API2 for me is the new property names. To support both new and old, you need 2 versions. There’s no way I can find to have one property with two names and show the right one in the inspector. Property setting order is also unpredictable, so getting the right one to override the other and load the value from an older IDE etc is almost impossible if not just straight up impossible. I’m probably going to just write a second subclass for API2 for people that want to use the new names.
@pidog: Don you have a feel for how much uptake there is of API 2.0 in your customers? I for one am all in on API 2.0 but I’m very aware that many are holding back due to being stuck on pre- 2019 releases.
