SourceCode Only

[John R. Heathcote]

Rod,

Maybe I should not be commenting because Stan is the guy that has the Tokenizer in the grip of his mind.

Please don't take this position. I value your comments as well as comments from all of the other participants. The idea is to get the discussion started and then to proceed in an orderly direction. The VB to PB conversion issue is so massive and complex that I feel if we have creativity, suggestions, or just a casual observation in any area we all had better listen to the same comment/observation. I think this is how we got to this point, by presenting our ideas for evaluation and consideration.

Besides, anybody who can come up with "MINISTER of OBNOXIA" and the "Howdedodat" button, is a pretty creative and witty guy.

[Rodney Hicks]

Please don't take this position.

Actually it wasn't really a position, I felt I might be muddying the waters unnecessarily since you two had this well in your grasp. Further, I hadn't considered a recursive system for the conversion and possibly should have and I didn't clue in until your response.
I was not withdrawing from the discussion because somebody disagreed with me. I had just discovered that my posit might be untenable. Back to the drawing board, for me, kinda thingy.
Besides, I reserve the right to be wishy-washy.

[Rodney Hicks]

Attached is a new Edit/View program(unfinished) for the dictionary based on that latest TYPE.

Only the 'Select Mode','Quit/Exit', and the LEVEL 'View' buttons are functioning so far.
There is a space provision to inform of search errors, not yet visible, but there nevertheless.
The only two comboboxes I have functioning are the 'Search in' and the 'Level'
at this point.
The LEVEL 'View' button gives daffynitions for the EQUATES for LEVEL in a MSGBOX.
Should anyone have ideas that might make this little tool better, let me know.
As usual in the programming world, nothing is etched in stone.

The zip file contains the exe and source code. It might be nice if someone let me know if there are any issues when the source code is compiled in PB 9. Since I'm still kicking myself about how I ordered.

[StanHelton]

...
The zip file contains the exe and source code. It might be nice if someone let me know if there are any issues when the source code is compiled in PB 9. ...

Compiles and runs without errors in PB 9.0. Good job, Rod. More intuitive than my efforts. Drive on!

Stan

[Rodney Hicks]

A side note. While constructing the MSGBOX string in that tool I discovered that the PB 8.04 IDE limits to 256 characters width per line which of course can be exceeded with line continuation character( _ ).

[StanHelton]

COM interface editor <==> converter

Here's the code. It's not finished, but you guys can see where I'm going and offer any help/ideas/suggestions.... and/or obnoxiousness.

Originally, I was going to make this part of the Tokenizer, but it kind of rewrote itself into a DLL server to both the Tokenizer and the Editor. My current thought is that the Tokenizer will run without any intrinsic windows or dialogs other than necessary MSGBOX things. Especially would like to hear what you guys think about running it this way: editor in the foreground, tokenizer in the background, communication through this server.


This is PB 9 code.

'vb2pbMessageServer
'   COM Interface
'   8/30/2008
'-------------------


#COMPILE DLL
#DIM ALL

%USEMACROS = 1
#INCLUDE "Win32API.inc"


'------------------------------------------------------------------------------
#INCLUDE "vb2pbEquates.inc"

'COM equates
$ConverterGUID              = GUID$("{20080829-2008-0001-0000-000000000001}")
$vb2pbCOMInterfaceGUID      = GUID$("{20080829-2008-0001-0000-000000000002}")
$StatusGUID                 = GUID$("{20080829-2008-0001-0000-000000000003}")
$COMEventsGUID              = GUID$("{20080829-2008-0001-0000-000000000004}")
$EventClassGUID             = GUID$("{20080901-2008-0001-0000-000000000005}")
$EventMessageHandlerGUID    = GUID$("{20080901-2008-0001-0000-000000000006}")
'------------------------------------------------------------------------------
#INCLUDE "vb2pbTypes.inc"
'------------------------------------------------------------------------------
#INCLUDE "vb2pbGlobals.inc"

'COM globals
GLOBAL ghInstance AS DWORD
GLOBAL oConverterInterface AS Tokenizer
GLOBAL oEventMessages AS EventMessageHandler
GLOBAL oEditorInterface AS vb2pb
'------------------------------------------------------------------------------

'-------------------------------------------------------------------------------
' Main DLL entry point called by Windows...
'-------------------------------------------------------------------------------
FUNCTION LIBMAIN (BYVAL hInstance   AS LONG, _
                  BYVAL fwdReason   AS LONG, _
                  BYVAL lpvReserved AS LONG) AS LONG

    SELECT CASE fwdReason

        CASE %DLL_PROCESS_ATTACH
            'Indicates that the DLL is being loaded by another process (a DLL
            'or EXE is loading the DLL).  DLLs can use this opportunity to
            'initialize any instance or global data, such as arrays.

            ghInstance = hInstance

            DIM oConverterInterface AS Tokenizer
            DIM oConverterMessages AS EventMessageHandler
            DIM oEditorInterface AS vb2pb

            LET oConverterInterface = CLASS "ConverterCOM"
            LET oEventMessages = CLASS "EventClass"
            LET oEditorInterface = CLASS "ConverterCOM"

            EVENTS FROM oConverterInterface CALL oEventMessages
            EVENTS FROM oEditorInterface CALL oEventMessages

            'code conversions array
            DIM Concordance(1 TO 1) AS GLOBAL ConcordanceType          'array for VB & PB code lines w/indexed line nos.

            'register as Windows Server
            SHELL "regsvr32.exe vb2pbCOMinterface.dll"

            FUNCTION = 1   'success!

            'FUNCTION = 0   'failure!  This will prevent the EXE from running.

        CASE %DLL_PROCESS_DETACH
            'Indicates that the DLL is being unloaded or detached from the
            'calling application.  DLLs can take this opportunity to clean
            'up all resources for all threads attached and known to the DLL.

            EVENTS END oConverterMessages
            LET oConverterInterface = NOTHING
            LET oEventMessages = NOTHING
            LET oEditorInterface = NOTHING

            'unregister as Windows server
            SHELL "regsver32.exe /u vb2pbCOMinterface.dll"

            FUNCTION = 1   'success!

            'FUNCTION = 0   'failure!

        CASE %DLL_THREAD_ATTACH
            'Indicates that the DLL is being loaded by a new thread in the
            'calling application.  DLLs can use this opportunity to
            'initialize any thread local storage (TLS).

            FUNCTION = 1   'success!

            'FUNCTION = 0   'failure!

        CASE %DLL_THREAD_DETACH
            'Indicates that the thread is exiting cleanly.  If the DLL has
            'allocated any thread local storage, it should be released.

            FUNCTION = 1   'success!

            'FUNCTION = 0   'failure!

    END SELECT

END FUNCTION
'========================================================================
CLASS EventClass $EventClassGUID AS EVENT
    'MessageEventHandler
    'events may take parameters, but DO NOT return a result

    INSTANCE ConverterStatus AS LONG
    INSTANCE LastInfo AS LONG
    INSTANCE LastWarning AS LONG
    INSTANCE LastError AS LONG
    INSTANCE LastFatalError AS LONG


    INTERFACE EventMessageHandler $EventMessageHandlerGUID AS EVENT
        INHERIT IUNKNOWN

            '%IsPaused, %IsReady, %IsRunning, %IsFinished, %IsSearching, %IsEditing, %IsBrowsing, %Saved_WIP
        METHOD EventMessage(BYVAL Message AS LONG)
            'possible messages are:
            '   Converter Status (Values from vb2pbEquates.inc):
            '       %IsPaused, %IsReady, %IsRunning, %IsFinished, %IsSearching, %IsEditing, %IsBrowsing, %Saved_WIP
            '   Editor Messages (Values from vb2pbEquates.inc - adjusted to be unique within application):
            '       %Info: 1, 1100 - 1200
            '           %Success = 1101
            '       %Warning: 1201 - 1400
            '           %OptionExplicit_NotFound = 1201
            '       %Error: 1401 - 1600
            '           %VB_SourceCorrupted = 1401
            '           %VB_StructureWithoutEND = 1402
            '       %FatalError: 1601 - 1800
            '           %UndefinedFatalError = 1601
            SELECT CASE Message
                CASE IS %IsPaused, %IsReady, %IsRunning, %IsFinished, %IsSearching, %IsEditing, %IsBrowsing, %Saved_WIP

                CASE IS %Success

                CASE IS %OptionExplicit_NotFound

                CASE IS %VB_SourceCorrupted

                CASE IS %VB_StructureWithoutEND

                CASE IS %UndefinedFatalError

            END SELECT

        END METHOD

    END INTERFACE

END CLASS


CLASS ConverterCOM $ConverterGUID AS COM
    'object instance variables
    INSTANCE vbCodeBlock AS STRING
    INSTANCE pbCodeBlock AS STRING
    INSTANCE ConversionProgress AS LONG


    'COM event source for Connection Point
    EVENT SOURCE EventMessageHandler
    EVENT SOURCE DISPATCH

    'internal Tokenizer Interface
    INTERFACE Tokenizer AS HIDDEN       'hidden from COM clients
        INHERIT IUNKNOWN

        'Tokenizer call to get VB6 code
        METHOD CodeToConvert AS STRING
            RAISEEVENT EventMessageHandler.EventMessage(%IsRunning)
            METHOD = vbCodeBlock
        END METHOD

        'Tokenizer call to set PBWin code
        METHOD ConvertedCode(BYVAL IN sText AS STRING)
            RAISEEVENT EventMessageHandler.EventMessage(%IsFinished)
            pbCodeBlock = sText
        END METHOD

        'Tokenizer call to SET progress
        METHOD ConvertProgress(BYVAL IN lNo AS LONG)
            STATIC ConversionProgress



            ConversionProgress)
            RAISEEVENT EventMessageHandler.EventMessage(lNo)
            ConversionProgress = lNo
        END METHOD

    END INTERFACE



    'COM server interface
    INTERFACE vb2pb $vb2pbCOMInterfaceGUID      'exposed to COM clients
        INHERIT IUNKNOWN


        'published COM for client to GET PB code
        PROPERTY GET pbCode() AS STRING     'r/o
            PROPERTY = pbCodeBlock
        END PROPERTY

        'published COM for client to SET VB code
        PROPERTY SET vbCode(BYVAL sText AS STRING)      'w/o
            vbCodeBlock = sText
        END PROPERTY

        'published COM for client to check progress
        PROPERTY GET Progress AS LONG       'r/o
            PROPERTY = ConvertProgress
        END PROPERTY

        'published COM for client to send messages
        PROPERTY SET vb2pbMessage(BYVAL lMessage AS LONG)
            RAISEEVENT EventMessageHandler.EventMessage(lMessage)
        END PROPERTY

    END INTERFACE

    EVENT SOURCE EventMessageHandler

END CLASS

[Michael Mayerhoffer]

I have all archives in one place now 358 gigs worth

I found an early stage of my converter, it is in c. I have a better handle on what I am looking for and time stamps don't mean squat. I have intermixed time frames.

Just thought I would update everyone that I am still searching, looking and working on the project. I am hoping to contribute to this one way or another. Very shortly .. Just not hot air service.

Mike

I hope this was a good place to post this

[Rodney Hicks]

Michael,

I hope this was a good place to post this

Any place is a good place to post good news!

Stan,
I took a quick look at the code. I'm not sure that I can get my head to go in too many directions at once, but when I return in a few days I hope to have comments. I realize that they'll be days late and dollars shy.

[StanHelton]

I have all archives in one place now 358 gigs worth ...

I'm impressed. I've got only about 20 gig that was worth saving.

...
I am hoping to contribute to this one way or another. Very shortly .. Just not hot air service....

What did you think of the admittedly raw and incomplete server I posted? I would be very interested in your comments if you could take a moment to look at it.

...
I'm not sure that I can get my head to go in too many directions at once, but when I return in a few days I hope to have comments. I realize that they'll be days late and dollars shy.

Don't wrestle with it too much, Rod. The dictionary file is more important. I think that between Mike and me we should be able to handle this server thingy. Can hardly wait to see what obnoxiousness John wants out of it to make the editor work

Be safe and be well on your trek.

Stan

[John R. Heathcote]

Stan,

Can hardly wait to see what obnoxiousness John wants out of it to make the editor work

Well there really isn't any obnoxiousness (is that a word, if not, it is now) needed for the editor to work. I've tried to keep the interface between it and the Tokenizer as separate and as simple as I can get it. Right now, the editor can pass as few or as many lines as the Tokenizer needs to do its thing. With the Tokenizer passing back the converted line(s) along with a status of success or failure, I'm pretty much set. All I really need at this point is the Tokenizer calling sequences, property sets, etc. I'm sure there will be many changes necessary in the editor to successfully merge the capabilities of the Tokenizer, but that goes with the territory, so no biggie.

What did you think of the admittedly raw and incomplete server I posted?

Like Rod, I guess I'm having a hard time seeing the advantage of a server based process. Are you planning to give the user the capability of running the Tokenizer as a separate process without the editor? I'm ok with that, but based on the limited VB to PB conversions I've done so far it is much easier with the editor than without. On a large VB project I cannot imagine performing conversions without the editor. If there is one thing I've learned from my conversions is visual feedback is very important as the conversion process is iterative in nature.

BTW, the editor recoding effort from Firefly to SDK is proceeding well for a change. Hopefully I will be able to send it to you sometime this week as I promised, assuming Murphy doesn't show up again. He is the true MINISTER of OBNOXIA, I learned everything I know from him.

I'm also working on converting some of the Firefly utilities I've developed as they will assist the user in code formating, maintenance, manual coding etc. I have most of these recoded, but need to test them. A tidbit of information you might be interested in is that I'm using the source code utilities for the editor to help write and clean up the editor.

[Michael Mayerhoffer]

I'm impressed. I've got only about 20 gig that was worth saving.


What did you think of the admittedly raw and incomplete server I posted? I would be very interested in your comments if you could take a moment to look at it.

Be safe and be well on your trek.

Stan

Stan
I believe I see your concept or what you want to accomplish. I see no reason for using or not using com, up to you.

After seeing the server sample, I realize I am missing some of the picture here.

I am trying to fast track the overall picture. I am asking more for a general flow of conversion not real detailed stuff.


general flow such as ---

open files in a editor - process - complete and mark troubling code..

or open files - process - stop and advise correct what ever - Please play again to complete.



This would really help me catch up jumping in the middle of things.

Thanks

Mike

PS I think that the self registering part would be a viscous loop. You would have to load the DLL and it would then register and re-entry would cause it to re register... ... ... ...

[StanHelton]

Stan
I believe I see your concept or what you want to accomplish. I see no reason for using or not using com, up to you.

Thanks for the feedback Mike. The interaction John and I have been planning is for the editing to take place in an application he is writing based on Scintilla. My idea was to run the converter separately, but now I'm not so sure after working with the COM interface for the last day and a half with Mr. Murphy looking over my shoulder.

After seeing the server sample, I realize I am missing some of the picture here.

I am trying to fast track the overall picture. I am asking more for a general flow of conversion not real detailed stuff. ...

General flow:
1 - open files in editor
2 - ==> pass selected VB code to tokenizer
3 - ==> pass PB code back to editor
4 - ==> user has option to accept, decline, manual edit
5 - ==> process repeats until user is satisfied or quits in frustration

I'm not sure how John is implementing the user options, but here's a list of what relates directly to the converter:

Line-by-line
Procedure-by-procedure
File-by-file
Whole Project

Given your initial comments and my 2-day headache with COM, I'm beginning to think we would be better off with one huge executable that uses internal objects and events. John is subsuming most (if not all) of the user editing functions into his app. I've stripped most of the dialogs out of the converter. That would greatly simplify the need to pass messages; we could just set flags and procedure return values.

PS I think that the self registering part would be a viscous loop. You would have to load the DLL and it would then register and re-entry would cause it to re register... ... ... ...

You are absolutely right! I had to take that out on the first test run after I posted that code. Beginning to think I forgot the KISS principle when I thought this up .... again.


Stan

[John R. Heathcote]

Stan and Michael,

...and a half with Mr. Murphy looking over my shoulder.

Murphy seems to be everywhere, he seems to visit me on a regular basis.

I'm not sure how John is implementing the user options, ...

Right now the only user options I've implemented is to load and save specified file(s) from the OpenFile and SaveFile dialogs. The user clicks on a loaded file in the editor to make it the current file (assuming more than one file is loaded at a time). From there the user would select a conversion level and begin the conversion process. There are tools to assist the user in cleaning up the converted code.

Obviously one user item I would like to add is to handle conversion on a project level, but I think that may have to wait until a later version as I'm unsure exactly how we want to set up this feature. For now, I think the loading of files in this manner will suffice.

General flow:
1 - open files in editor
2 - ==> pass selected VB code to tokenizer
3 - ==> pass PB code back to editor
4 - ==> user has option to accept, decline, manual edit

This is the way I envision it too.

5 - ==> process repeats until user is satisfied or quits in frustration

Or far too many OBNOXIOUS COMMENTS.

Changes made to VB code will be reflected in the editor so the user will have a visual feedback of the process as it occurs.

Before we get too wrapped up in details I think we need to merge the Tokenizer and the editor together to see what the ramifications are before we proceed further.

[Michael Mayerhoffer]

Stan

that makes things much clearer now.

John moving that to PB or leaving it as is ?

Leads me to more questions and thoughts, I will get back to you tomorrow or so. Need to rest a bit for now.


------ John I agree, get back to you too... forgot to post this and seen you posted while this was sitting in no where land..did not want to think I ignored your post.


Mike

[StanHelton]

John and Mike,

...
the loading of files in this manner will suffice.

I had a dream last night. Mike has tickled my brain into coming up with a better method that should have been obvious.

I think you said you're writing the editor in PB (with some FireFly?). In that case, why don't I just make the Tokenizer files #INCLUDEs for the editor? Everything in one place and normal procedure calls to access the various parts. Since I've got the event CLASS and the COM CLASS mostly built, we could use internal objects to handle the messaging (no GUIDs required) and the GLOBALs would be available to both editor and converter because they are one and the same. With this method, program flow doesn't change, but implementation gets a whole lot easier.

For whole file conversion the Tokenizer does a synchronous SHELL to the parser which separates everything out, builds the VB Terms array, and saves it as a file with ".parsrpt" extension. Multiple files can be processed in a single SHELL. There's a DragAndDrop listbox in the converter for processing multiple files as a batch. Might be able to use that for the WholeProject option. Right now it's pure DDT. We'll have to see if it's compatible with the editor.

...
Changes made to VB code will be reflected in the editor so the user will have a visual feedback of the process as it occurs.

As a merged program the editor will have access to the GLOBAL Concordance array. Text can be placed/pulled/edited directly from that if we want, or we could, probably should, use a string buffer and let the Tokenizer do the direct modification to the Concordance.

Probably should define the conditions for the editor to REDIM the Concordance: Tokenizer fiddles with it alot. Or we could just use the internal objects. (thinking as I type.... almost always a mistake. ) Oops, that's a detail, isn't it.

Before we get too wrapped up in details I think we need to merge the Tokenizer and the editor together to see what the ramifications are before we proceed further.

Exactly! ... ok, so I'm coming late to this particular party, I'm here now.

Give me a few hours to modify the Tokenizer files appropriately and I'll post them here in a zip. I need to chop up the parser a little bit also to get the appropriate functions into the Tokenizer proper (instead of using SHELL).

Stan

BTW, if you have the editor code in a state I could work with, we could compare notes once we've each run our own tests on the merger. sjh

[John R. Heathcote]

Stan,

I think you said you're writing the editor in PB (with some FireFly?).

No. The editor has been rewritten so that it is a pure PB SDK/DDT app, no Firefly involved, however, since it is a MDI app I had to use mostly SDK rather than DDT. I thought no third party GUI/RAD tools were to be used. Wasn't this the goal we set for ourselves?

In that case, why don't I just make the Tokenizer files #INCLUDEs for the editor? Everything in one place and normal procedure calls to access the various parts.

We can do that too. It should be easy as I've tried to keep the editor functionality separate from the Tokenizer.

With this method, program flow doesn't change, but implementation gets a whole lot easier.

Agreed.

For whole file conversion the Tokenizer does a synchronous SHELL to the parser which separates everything out, builds the VB Terms array, and saves it as a file with ".parsrpt" extension. Multiple files can be processed in a single SHELL.

I think we will have to let the user decide which conversion method is the better one to employ, to let the editor always feed the Tokenizer what it needs, or let the user pass the VB file directly to the Tokenizer and then view the results. Either method is doable.

The conversion method used would also be dependent on the complexity of the conversion requirement itself. I think for large projects the user may want to keep tabs on the conversion as it progresses, so the editor feeding the Tokenizer would be used. Perhaps on smaller conversions the user might want to let the Tokenizer do a batch convert then view the results. I can see instances where both conversion scenarios would be applicable.

There's a DragAndDrop listbox in the converter for processing multiple files as a batch. Might be able to use that for the WholeProject option. Right now it's pure DDT. We'll have to see if it's compatible with the editor.

I don't foresee any immediate problems. The trick is to keep both processes separate from each other and define the data passing mechanism for the editor and Tokenizer. In this way the data passing mechanism is the only direct communication the editor and Tokenizer have with the other process. Limiting communication with both processes allows for updates to occur to the editor and Tokenizer pretty much independent of the each other. Although it does not totally eliminate recoding it does minimize it to a great degree.

As a merged program the editor will have access to the GLOBAL Concordance array. Text can be placed/pulled/edited directly from that if we want, or we could, probably should, use a string buffer and let the Tokenizer do the direct modification to the Concordance.

Doable. In this case, I tend to think we should let the Tokenizer determine how it wants the data, how much data to send, and what is more convenient to do from a conversion processing stand point. The Scintilla edit control permits access of the text in a variety of ways, so the flexibility is there if we decide to use it (I just have to figure out how it works). If I need to pass an array of VB source code, or a string buffer to the Tokenizer, both can be done easily. I just need to know the specific data formats so I can create them correctly on the editor side.

One thing I don't want to do is to allow the Tokenizer to directly alter the text in the edit control. I have many reasons for this, but primarily it will be extremely difficult to keep track of the current line/position in the editor. In this case we could trash the resulting output file in the edit control by not keeping meticulous track of the text cursor. I am of the opinion that if it is a matter of text display let the edit control handle that chore, if it is a conversion let the Tokenizer handle that.

Probably should define the conditions for the editor to REDIM the Concordance: Tokenizer fiddles with it alot.

Agreed. I think we really need to tie down the data passing mechanism specification so we both know what we are doing.

BTW, if you have the editor code in a state I could work with, we could compare notes once we've each run our own tests on the merger.

The editor is pretty close to a workable state, if not there already. I still plan on getting what I have to you this week. Murphy paid me a visit again last night. I thought he was working with you.

[StanHelton]

...
I think we really need to tie down the data passing mechanism specification so we both know what we are doing.

I'll make this my top priority for the rest of the day. I agree with all the points you make.

The editor is pretty close to a workable state, if not there already. I still plan on getting what I have to you this week. Murphy paid me a visit again last night. I thought he was working with you.

You don't think there might be TWO of them?

I've got a lot of things going on right now: this big business trip, a few unruly clients, and some impatient creditors. Please forgive if I forget somethings from moment to moment.

Stan

[John R. Heathcote]

Stan,

I'll make this my top priority for the rest of the day. I agree with all the points you make.

Thanks. I guess we are on a roll.

You don't think there might be TWO of them?

Or more. Murphy seems to get around a lot.

I've got a lot of things going on right now: this big business trip, a few unruly clients, and some impatient creditors.

I understand, sounds like we have the same creditors.

Please forgive if I forget somethings from moment to moment.

I have to make the same claim, but in my case, my forgetfulness is due to the fact I whacked my head.

I'm going to give my problems Murphy created one more shot at fixing them, but in any case, I will send you the editor as it stands now. It should be well enough to let you know where I'm going with it.

[Michael Mayerhoffer]

Murphy is the master of multi tasking - he is visiting me too on several levels.

Update---

I am piecing together what bits and parts I found, soon as I can, I will donate a complete working concept model ? The missing parts I am putting in minimum code to get the point across.

I am thinking it may or may NOT be a starting point for a new version down the road. Might be just something to get ideals from or something to laugh and point at.

FWIW I did not ever use an editor for conversion stuff. VB straight to PB files. Makeddt - header and RC files in -Ready to use DDT code.

Makeddt code was part of the VB to PB code converter. :crying2:


Back to business here, soon as that diamond in the rough gets packed together, I can provide more hot air service ..

[StanHelton]

...
Update---

I am piecing together what bits and parts I found, soon as I can, I will donate a complete working concept model ? The missing parts I am putting in minimum code to get the point across.

I am thinking it may or may NOT be a starting point for a new version down the road. Might be just something to get ideals from or something to laugh and point at.

FWIW I did not ever use an editor for conversion stuff. VB straight to PB files. Makeddt - header and RC files in -Ready to use DDT code. ...

Mike,

One of the dormant cogs in my brain just kicked in. You've mentioned this before, but I didn't make the connection.

Is MakeDDT a standalone app? What I'm getting at is, could MakeDDT eliminate the need for the end user to own a copy of PBForms?

Stan