19 replies to this topic

[Kilburn]

Okay, this is not a so important scandal, because these are not many C++ programmers here.
But I wonder why Casio doesn't support the SDK, and WHY THEY HIDE US THE HIDDEN FUNCTIONS FOUND IN THE LIB FILES.
These are many many many (>1,000) hidden functions, and they are very interesting, such as LibBuzzerOn(), which allows to sound the buzzer. And there is a fact which is more scandalous : Greg, who programmed My Programs add-in, used one of them, but is forbidden to give it to us!
And Casio also deleted the secret menus, and many math functions are hidden (completeSqr, element, insert...). And they hid us the possibility to add If, While, etc... commands in functions (PRGM Conv).

If someone can explain me why THEY hide so many features, I would be very VERY HAPPY to listen at him.

[Orwell]

Da*n, how many times should it be repeated again and again

Casio has its own politics, and it's very normal that they decide what features of their products they will offer to their users, and what will stay hidden. Don't forget that the ClassPad is a commercial product, it is not an free or open source project! It is their right to hide the internal structure of the CP if they don't want us (as simple users) to know how it works. And it is also their right to provide all the needed informations to their collaborators (like Saltire), and to forbid them to share it among the user community.

We already discussed many times about the buzzer support, and I think that things were clear: Casio does not want it to be supported simply because there is a possibility that the future ClassPad models won't have a buzzer anymore, and thus every programs using it would bring some boring incompatibilities among the different models.
Furthermore, Greg is a worker at Saltire, which is bound with Casio by contract, and you don't have to compare our position and his position. And about the secret menu: well, this is a secret menu, so it must remain secret, that's all. What's the point to have a secret menu if everybody has access to it?

I also would like Casio to provide us more information about the ClassPad's internal stuff, but we already have a nice SDK and support from Saltire; remember the case of the AFX for which we didn't have any support at all Between a limited support and no support at all, I gladly choose the first solution. So stop complaining, and let's work hard all together to "complete" the SDK with some other interesting stuff

Edit: Consider my CPLua project. There are different things that are partly available, but about which I do not discuss for now, because it is possible that I will change it in the future versions or because it needs a lot of explanations to understand how it must be exactly used. Those things are hidden to protect reckless users from possible crashes or bugs due to an incorrect use of those features. Should I be blamed for that?
Therefore, if I would want to work with another collaborator, I would give him the details about some of those "hidden" features because I'm sure that he would use it in a correct manneer, and so he would be able to do some great things with it; but I would not want him to talk about that to any person whose not related to CPLua's development

[fiberoptik]

I wouldn't say it better...

[PAP]

Edit: Consider my CPLua project. There are different things that are partly available, but about which I do not discuss for now, because it is possible that I will change it in the future versions or because it needs a lot of explanations to understand how it must be exactly used. Those things are hidden to protect reckless users from possible crashes or bugs due to an incorrect use of those features. Should I be blamed for that?

No, you shouldn't be blamed for that, although I would like to know all these CPLua "secrets" . But you are right, "secret" features in every application stay hidden just because they are incomplete and they need further debugging, or because the developer has not decided yet if he will include them in future versions or not. In my project, LuaNumAn, there are also some "secret" features which are not explained nor mentioned in the manual, in order to prevent inappropriate use. I think that this is natural, and happens to every application that is still in progress. You should not be blamed for not revealing all secrets of CPLua, but I should not be blamed as well, just because, as a CPLua programmer, I want to know these "secrets".
Like you said, ClassPad is a commercial product, and, unfortunately, its OS is not an Open-Source software, so it may contain plenty of "secret" features. But you should understand that every SDK programmer wants to know all the ClassPad "secrets"; this is natural. Casio has decided not to reveal some secret features, and, indeed, Casio, as a manufacturer, has the right to do that. On the other hand, Kilburn wants to know more about his ClassPad, and he has right as well; he should not be blamed for that. My personal opinion is simple: yes, I understand that a manufacturer may hide some features for many reasons, but if I must choose between a brand that sells a commercial product and a user, I will take the user's side, definitely.

[Kilburn]

Therefore, if I would want to work with another collaborator, I would give him the details about some of those "hidden" features because I'm sure that he would use it in a correct manneer, and so he would be able to do some great things with it; but I would not want him to talk about that to any person whose not related to CPLua's development

Could I be this collaborator? I can keep a secret, you know...

I understand that Casio hides some features, but knowing that other people know them could be rather disgusting! :x
It is a great pity that they can program better add-ins, just because they know the hidden features.
If Brian didn't tell us secret features, such as CPKeyboardManager, you could never add a tiny keyboard in CPLua!

[Orwell]

I understand that Casio hides some features, but knowing that other people know them could be rather disgusting! :x
It is a great pity that they can program better add-ins, just because they know the hidden features.

You are just confused because Saltire is different from Casio. If it was not the case and if Brian or Greg were actual Casio employees, you wouldn't find it disgusting but just normal. There is nothing "disgusting" here, there is a contract between Casio and Saltire, and you have nothing to say about that. Perhaps you should create your own company, then contact Casio to engage you for the development of their next calculator

If Brian didn't tell us secret features, such as CPKeyboardManager, you could never add a tiny keyboard in CPLua!

This is something that we, as users, see as a good thing, but maybe Casio would not find it really great, because we are not using their product in the exact way they wanted...

[PAP]

This is something that we, as users, see as a good thing, but maybe Casio would not find it really great, because we are not using their product in the exact way they wanted...

Hmmm, I want to use any product I buy in the exact way I want, not in the exact way that someone else wants, even if it is its manufacturer, or god itself, or whoever.

[CrimsonCasio]

just be glad you wernt here a few years ago

[Orwell]

Maybe you're right, but then you must keep in mind that you are responsible for any bad consequences that could happen if you use some of those "unsupported" features. It seems natural for programmers like us, because we know the tricks that we use in our programs, and if something goes wrong (and if we see it) we will try to fix it quickly.

However, I'm afraid that many simple users will forget that they use some programs made by "amateurs", and there is a risk that they will reproach Casio with some undesirable effects. For example, most of the current add-in games are draining the batteries really fast, even though the Casio engineers made their best to preserve the batteries in the basis modes of the CP.
If the users are not correctly warned by the programmers, they could get unsatisfied by some aspects of their ClassPad, and it is not sure that they will allways accuse the authors of the programs they use, before Casio's engineers.

Then you will reply me: "That's simple, every programmer has the obligation to warn the users of each unsupported features used in his progs, and of each possible undesirable consequences". It's true, but look at the different add-ins that are available on classpad.org: almost nobody did it correctly, and this is exactly what Casio doesn't want

[SoftCalc]

Furthermore, Greg is a worker at Saltire

Actually, Greg is a Casio employee. I am a Saltire employye working UNDER CONTRACT for Casio (i.e. my paycheck comes from Casio)

As far as the secret menu, people could corrupt their ClassPad and it wouldn't boot. After a few ClassPad returns I can see why they removed it.

This is something that we, as users, see as a good thing, but maybe Casio would not find it really great, because we are not using their product in the exact way they wanted...

Casio does not mind . If it's good for the ClassPad why would they mind?

[Orwell]

For the same reason that they removed the secret menu: we will soon be able to customize more and more things in the ClassPad, but there is a possibility that this could lead to memory corruption etc if it not used exactly as it should (and it's not easy because of the lack of information we have)...

[CrimsonCasio]

inversely though, a few people saved their classpad via reseting it through those menus (qwerty for example)

[PAP]

just be glad you wernt here a few years ago

If I understood well, this statement goes to Kilburn, Orwell, or me. In any case, I don't see why the presence of any of these persons in this forum is something so bad. I hope you were just joking.

Maybe you're right, but then you must keep in mind that you are responsible for any bad consequences that could happen if you use some of those "unsupported" features. It seems natural for programmers like us, because we know the tricks that we use in our programs, and if something goes wrong (and if we see it) we will try to fix it quickly.

Yes, it's obvious to every programmer. It should be obvious to the users too; if it's not, it's a user's fault .

If the users are not correctly warned by the programmers, they could get unsatisfied by some aspects of their ClassPad, and it is not sure that they will allways accuse the authors of the programs they use, before Casio's engineers.

Indeed, a naive user will probably accuse Casio in the first difficulty he/she may encounter. But, again, this is a user's fault. However, I can see a reason for hiding special features to prevent this, although I still don't agree.

Then you will reply me: "That's simple, every programmer has the obligation to warn the users of each unsupported features used in his progs, and of each possible undesirable consequences". It's true, but look at the different add-ins that are available on classpad.org: almost nobody did it correctly, and this is exactly what Casio doesn't want

You are right, almost nobody warns the user. Well, this is an unsolvable problem, since we canot force anyone to publish a freeware program the way we want. Maybe Saltire may add a statement about this in the "download" section.

[Orwell]

just be glad you wernt here a few years ago

If I understood well, this statement goes to Kilburn, Orwell, or me. In any case, I don't see why the presence of any of these persons in this forum is something so bad. I hope you were just joking.

Wow, I'm afraid you didn't understand: he just said this because there was no SDK at all a few years ago, and the situation is clearly better now; so we shouldn't complain too much about the current possibilities of the ClassPad

[PAP]

Wow, I'm afraid you didn't understand: he just said this because there was no SDK at all a few years ago, and the situation is clearly better now; so we shouldn't complain too much about the current possibilities of the ClassPad

Hmmm, that statement was immediately after my post, and without any quote, hence the misunderstanding. Indeed, the situation is much better now, but it is always possible to become better .

[CrimsonCasio]

well, a few years ago we were stuck with the CFX, no casio contact, and basically squat... thats what i was refering to it was an act of supream effort to do the simplest things. strings for example >_<

this is heaven in comparison

[PAP]

well, a few years ago we were stuck with the CFX, no casio contact, and basically squat... thats what i was refering to it was an act of supream effort to do the simplest things. strings for example >_<

this is heaven in comparison

This reminds me the time I was using an old Casio basic programmable model, having only 1640 bytes of RAM (a friend offered it to me). This was real hell in comparison: There was a single 12-character line, together with a byte counter. You was able to write up to 10 programs in a primitive basic, and saving/loading into tapes was a real nightmare. Of course, "CAS" and "SDK" were unknown words, no Casio support at all, no PC connection. The worst thing was the "free bytes horror": each time you was writing a new command, the byte counter decreased dramatically. Despite all these limitations, which are unbelievable today, this thing was useful. In fact, the limitations forced the user to write as much robust programs as he could.

[Filip Georgijev]

What should I say for me? My story as a Casio user started working on fx-6300G - the same situation, but only 400 (four hundred) b (bytes) of RAM! However, it inspired me too. All the other things were the same...

[CrimsonCasio]

In fact, the limitations forced the user to write as much robust programs as he could.

exactly! trying to make efficent and usefull programs out of an inherently inefficant language tought me alot about programming in general, plus, it was challenging and fun

[Orwell]

The same goes for me