Wednesday, February 10, 2010

PROMIS TP Query written in VB6

Graph of typical Operating System placement on...Image via Wikipedia

After migrating all of my codes from VB6 to VB .NET 2003, then to VB .NET 2005, I now find that many of the 'complex' apps that are used in our company are never migrated over.

I learned that many of the libraries that were passed over by software vendors didn't include the source codes, so that tied up those applications to VB6 legacy.

Anyway, here's the real headache that I faced:

I had many process flows created that extended beyond the limit 'imposed' by that old code, which is 50 rows max, even if you specify a number higher than that in the code provided. So I was asking, why was that provision there, when it doesn't work in the first place? An empty promise, eh?

Anyway, no use asking why. So I said, I'll try to work out something from scratch.

So I did. I don't know where to begin, but I remembered that many, many years ago, when I started working on my very first codes using TP Query in VB6 platform, I did the same thing: take the example from the DMQ installation.

I did just that, but then, I never thought that I have completely forgotten VB6 coding. So I was paralyzed in all extremities. Cannot move, even an inch.

But a step has to be made, or at least, I know what I wanted to do: a simple form, bare-simple, and a simple code, stripped of complexities. just to make the code work by extending the number of rows that will be captured.

And then again, when I started working on VB6, I always asked my colleagues in the main IT line, and it is not for free. It is a sort of "quid pro quo" thing. I give, I take. I help you now, you help me later. It is always a bilateral interaction.

So even with the simplest line of code, I have to admit that I've no more knowledge of VB6 code. After trying out and copying from VB .NET codes, I find that these don't work, or that the syntax is already different, I called up my counterpart in IT, who is supposedly the recipient of this code I am working on. Thankfully enough, he is very patient to answer my lowdown questions.

I got my piece of code working bit by bit, and I was able to proceed step by step.

Then came another road block. I managed to get up to 100 rows, but no more. For 3 days I dwelt on the same problem, changing parts of the code here and there, enlarging string definitions, as I was thinking that maybe, it cannot take the large chunk of data being returned, etc., etc.

No progress.

In desperation, I fired a mail to the nearest PROMIS Support Team, and that confirmed my guess immediately! What was it about? That the 100 rows is a site-setting parameter. And the guy right away provided the steps and procedure to extend that limit.

Our system administrator immediately tried it out. There were some snags, and since it was Friday, we agreed to continue by next week. We don't want nobody to be spoiling their weekend, eh.

Came the awaited Monday (that was 8th-Feb-2010), and I was caught up in a number of items needing my attention. And I just saw the notification mail that the admin guy sent out, telling that he succeeded in setting the limit from 100 to 300. Right there and then I dropped what I'm doing, and dug up my code, changed also the limit from 100 to 300, and voila! It worked!

And for me to have a copy of that code, I'm putting it here. I actually searched high and low on my archive files, in all of the 4 PCs that I am using at work, and I wasn't fortunate to find my old VB6 codes. I have those samples that are downloadable, even those that I asked as samples from our IT team before, but they don't give a workable solution - so that made me creating a new set of codes.

And now that I have done it (again) after a long, long time, I'm keeping it here, for reference in the future, or for anybody who may need it.

To note: when the data being sent (Putmsg) or received (Getmsg) is getting bigger, the size of the string should be adjusted accordingly. I was trying String * 256 at first, then I'm getting that the data is bigger than the buffer, so I progressively changed that to 512, 1024, 2048, and so on.
What I now have that worked even with the longest process flow is Putmsg MsgArea String * 4096, and Metmsg MsgArea String * 8192 definitions.

Happy coding (once again) in VB6.
Reblog this post [with Zemanta]

No comments:

Post a Comment