MaxCoderz

Why, oh why did you have to make xlib use real(00 through real(30 ?
Whenever I run something that uses xlib, first I have to disable both Omnicalc and Symbolic, which makes Pretty Print just about worthless. I love those apps since I only do Basic programming. Without Omnicalc I can't restore my ram if my calc crashes (that happens alot b/c of all the testing I do on it ). I am forced to use your old buggy version of xlib that was an asm program, so I am missing a bunch of features. Is it not possible to change the real( function to somthing else

It's not that it's the real functions, it's that it's a parser hook. And the ram recovery still works fine for me. Someone is working on a hook manager that should make all that work better soon.

_________________
Shaun

Indeed it has nothing to do with the real( token, its the parser hook. I could change it to anything, like int( for example and it would still conflict with omnicalc.

Andy_J is making a hook manager for SoC, this will enable a range of hooks to be run concurrently.

_________________
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."

Except it won't work if you have apps that use the same numbers in real( -- one of you is going to have to change your numbers, which would break all preexisting programs using it. =\

How am I supposed to know if you mean real(10 from Omnicalc or from xLIB? I just can't do anything about something like that, sorry.

_________________

Indeed that is a problem. I call dibs on not changing!

_________________
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."

I think you and Michael should have a fight to the death.

_________________
Shaun

What if you and Michael found a way for the apps to chain like symbolic and omnicalc (which I know is just about imposible ) do, and then made a special version that used different tokens. That way, the all previous programs would not have to change their format.

I think backwards compatibility is more useful to people than breaking it just for omnicalc. I might be able to make a 'run omnicalc function' function though.

_________________
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."

But Omnicalc and Symbolic are the only apps that seem to have a big problem with it . Besides, the only people who need it to run at the same time are programmers.

I assume this would still disable symbolic's functions, as well as all of Omnicalc's non-programming options . Still, that would be really nice !

There's no reason for all of Omnicalc's other options to be forcibly disabled. Install Omnicalc, then install xLIB, and the only thing that shouldn't work in Omnicalc is its parser hook. Its key hooks and memory protection and all that jazz should still work.

_________________

Hmm.. .
It's actually been awhile since I even tried installing both, and that was when I used TI-OS v2.41, which had about 3 million bugs, so the ram clears and all that other crap may have just been TI's fault . Also, I used your previous version of xlib. Would that make a difference

Just tried it with the new version and it works

If I recall, xLIB did chain properly with Omnicalc, and the problem was just that it used the same function numbers as Symbolic. Someone could change the numbers that Symbolic uses, but the problem is that Omnicalc doesn't properly chain with Symbolic. Instead of passing the numbers to it's parser hook, it directly calls Symbolic's functions (I think), so both Symbolic and Omnicalc would have to be altered.

So, I think the one solution is for xLIB to have an option that switches between using the old numbers and using a new set of numbers compatible with Omnicalc and Symbolic. Then you'd choose whether you're interested in playing existing xLIB games or if you're interested in the new, compatible functions.

Another solution is for xLIB to determine whether the user wants to use it's function or Symbolic's function based on the number and type of parameters (for functions that have different parameters), and then passes on to Symbolic if necessary.

I'd say the first version is simpler to implement, but the second version could potentially be more compatible overall. If my post is hard to understand or is inaccurate, please let me know.

When tr1p says it's so, it's so.

_________________
Shaun

Merthsoft has a point, and iirc there wasn't a very much spare room in xLIB so uber cool omnicalc-detection might not even fit..
The hook chaining project is interesting though, would xLIB still conflict with omnicalc when the hook chainer is used? (where is that project by the way?)