To free, or not to free? That is the question.

I needed to get information out of D3 and there is no standard function to get it. After a couple emails with TigerLogic support, I was able to write two lines of code to get what I needed. Wow, that’s cool. Now should I be a good community citizen and give it away? Should I give anything away? In this two-part blog, I’ll explain in the first part the situation that prompted me to create a helpful little solution, and I’ll explain in the second part why I probably won’t give you that solution.

Here’s what started it all – the BASIC Prompt character. In BASIC (in D3 anyway) there is no native way to find out what the current prompt char is. That’s right, there’s no user exit or System() buffer or @variable that stores the prompt. The default is the question mark, so INPUT FOO displays “?”. You can change that with the PROMPT statement to something like “:” or “>”, but once you change it, there’s no way to find out what the prior prompt was.

Why would you want to know? Let’s assume program1 calls to program2. Program2 needs to do something that requires a transparent prompt. In my case I’ve been writing code that makes AccuTerm and AnzioWin do things like activating devices, sending data via FTP, faxing, scanning, emailing, etc. (Interested? Let me know!) My program2 does a CRT to the screen of the proper ESCape sequences and then does an INPUT to get the results of the operation. I use PROMPT “” to turn off the prompt so that the screen isn’t modified when I do my thing – it’s almost completely transparent. But how do I know what the prompt was from the calling program so that program2 can be a nice proggie and change it back?

Until now my solution was to leave it to the calling program to change the prompt back, something like this:

CALL PROGRAM2(P1,P2)
PROMPT ">" ; * or whatever program1 wants it to be

That’s not elegant because it leaves it to the caller to clean up after the program that’s called. We can also do this:

CALL PROGRAM2(P1,P2,">")

Then program2 will use PROMPT P3 to reset the prompt whenever it exits. That’s very tidy but it still requires a little extra housekeeping from the caller.

Those familiar with object oriented programming and the concepts of encapsulation will recognize a principle which says the caller of a routine should know as little as possible about how the called routine works. By asking the calling program to restore a prompt after doing something like sending a file via FTP, I’m betraying some of my internals, and darn it, that’s just too much for me to bear. _😉

Meanwhile, back at the ranch…

So I contacted TigerLogic support. The first response I got back was a firm confirmation that no, there is no current way to get that prompt information. I then received an automated response that an action item had already been filed for me, asking for the feature to be added. Cool, that’s the way the process should work.

My response was, OK, just tell me where the data is so that I can get at it myself. I know how to peek into frames, so if I know where the data is as an offset from the Primary Control Block or some other control block, then I can go get the info myself. The response came back instantly. I took that and created a little two-liner to return the current prompt. So now, program1 just needs to call, and program2 will save the current prompt, do its thing, then reset to the original prompt before it exits. Tidy, eh?

Gosh, other people may want to know how to do this

And so begins my dilemma. It’s only two lines, why not publish them here in the blog? How about sending the info to Spectrum to get published as a tech tip? How about just creating a posting in CDP or the TL forum and just let people take it if they want it?

From initial thought to completed function this R&D effort cost me about an hour. I can’t bill any clients for it. No, the hour came and went, as unbillable as the time I take to sleep or eat, and as unbillable as the hundreds of hours I spend coming up with other stuff like this that people can use but few will pay for.

So now I’m wondering why I give anything away – code, information, links to helpful websites, or referrals to companies who don’t give my company a commission on sales. Am I being curmudgeonly, or am I just following in the footsteps of countless others who sell their skills and laugh at the idea of giving anything away for free?

Stay tuned for Part 2, early next week…