Announcement

Collapse
No announcement yet.

Module Messaging Spec

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • John R. Heathcote
    replied
    Rod.

    It was a lot of work.

    Leave a comment:


  • Rodney Hicks
    replied
    Is it not our job as converter gods of creation to find a way to tie all the aspects of the VB, in this case a textbox and a button, together.
    I must mildly disagree with you my friend.
    Even I have to disagree with me. When I was creating that post I did some editing and I cut out more than I realized. It was supposed to be a funny line. Ah, well.

    We must merge the editor, Tokenizer, and Dictionary together now and see what happens.
    Couldn't agree more. Until we see these things operating together it is too hard to see which direction is the better one to go in when we come to a choice and it's too easy to get lost in details.
    You guys have done a tremendous amount of work, and letting and seeing your work work will work to make you a happy camper.(That sentence work for you?)

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

    As I mentioned to Rod I think we may be overstating the problem just a bit, getting lost in the details. The only way I see to know the full effect of what we are doing is to put the pieces together and try to make this converter thing work.

    Tokenizer keeps a log of line numbers associated with target terms...
    This being the case it doesn't make any sense to me to constantly update the Tokenizer arrays. Since your code appears to be set up to scan the VB file/procedure and rely on the critical targets it finds let's keep that functionality and let the editor create a separate PB conversion output dialog/edit box. This way we keep the VB input code and converted PB output code separate from each other. To make this work all I would need is a message from the Tokenizer that a change occurred in a source code line and to output that line, or the original source code line to the output dialog box.

    wow! Great Minds run along parrallel paths. I was looking at that code this morning. It is the most promising I've found so far. If you've already tweaked a bit, please share. Maybe we can integrate it in short order.
    I will send it to so you can take a look. Right now it is designed to read PB source code files and comment out the unused procedures, but it should work with VB code too.

    Leave a comment:


  • John R. Heathcote
    replied
    Rod,

    Originally posted by Rodney Hicks View Post
    ....

    When you create a form in VB with say a textbox and a button, adding whatever features you wish, VB must create all the files simultaneously. That is the frm file and whatever other file that handles all the features that aren't included in the frm file.

    PBForms only access the frm files and creates a skeleton for the project, then each of the features that VB relegates to another file have to be added to the output file in the appropriate places. The frm file may give the location and size of the textbox, but some other file will add the styles, and yet another file will add the manipulations, and yet another file will add the headaches.
    After viewing my VB form files the text to create the form as well as the individual event code for the controls and the form itself is also included in this code set. I believe the Callback Function(s) to make the VB event code work is included in the VB runtime module. All the VB user/programmer sees is the visual of the form and the individual event source code.

    Is it not our job as converter gods of creation to find a way to tie all the aspects of the VB, ...
    I must mildly disagree with you my friend. I think it is our goal to tie all aspects of VB together in order to generate a reliable PB conversion. I'm thinking of the relatively new (and maybe even an experienced) PB user who is running our converter. When the resulting PB code is generated they will be expecting it to work like their VB app. To do that we have to dig into the guts of VB and tie everything together that we can to make this work. I do agree that we may have to take this issue a step at a time.

    Can we not access the ShowDialog1 procedure(others as created by PBForms) and find the textbox features, then the button features from the other VB files and put them in their appropriate places in the ShowDialogx procedure or the Callback function.
    Yes, this was my idea as well, but the same functionality has to be duplicated in PB as well, we might not be forced to emulate the same VB events, but the functionality must be there.

    I am trying to ascertain if we are better off just getting the basics working, then adding a step here, a step there, etc. until it becomes time for a rewrite.

    We already have here in this forum a lot of capability, but we don't have it together in one place so that we can just add a new feature as we develop it.
    My sentiments exactly. We must merge the editor, Tokenizer, and Dictionary together now and see what happens.

    Leave a comment:


  • StanHelton
    replied
    Originally posted by John R. Heathcote View Post
    ....
    When the Tokenizer scans the file and locates its desired targets are those locations cast in concrete? Can they be moved? My reason for asking this is if we intend to comment out the VB portions of the code and insert the PB conversions in the same edit dialog then the total number of lines in the copy of the source file will change and thus destroy the original target locations found by the Tokenizer. Could we have a message to direct the Tokenizer to rescan from the next legitimate VB source line forward?

    Tokenizer keeps a log of line numbers associated with target terms (like CLASS, OPTION xxx, DIM, & etc.). If the message system sends an insertion point it's a simple matter to update the array (SpecialTerms().Term and SpecialTerm().LineNo). An %InsertAfterLineNo message ... and while I'm thinking about it, a %ReplaceLineNoWith message for when the user changes the VB source, just in case the SpecialTerms().Term needs to be changed or deleted. The new line would be passed as a VB code line in the usual way as a single line of code.

    For structures requiring more than one line of .... Pardon. I had a brain storm as I was typing. All of a sudden, multiple messages to get a whole structure seems a bit redundant.

    This may simplify the communication process. Suppose we have a GLOBAL gCurrentSourceFile() STRING array where each element is one line of the current VB source file. The Editor still has primary responsibility for this, but when it gets updated, the Toknzr only has to rescan the array to refresh the information. Allows for bigger changes by the user, even complete rewrites (which I am sure will happen) as the user edits his code. Reduces the number of times we have to pass things around internally. As I think about it, it will let me reduce the number of arrays the Toknzr has to maintain as well.

    The %ConvertThis message becomes a function call something like this:
    Code:
    FUNCTION ConvertThis(StartElement AS LONG, EndElement AS LONG) AS LONG
    Then function returns a status message to let the Editor know how it went. And the PB text could still be posted to the pbCodeBlock GLOBAL. The vbCodeBlock GLOBAL goes away. The SpecialTerms() array might go away too if the Toknzr has access to the entire file in this format. Tracking VB line nos. goes away because the array index is the line number. The Editor can use ARRAY SCAN/INSERT/DELETE and REDIM PRESERVE to update the array because it's a simple string array.

    We could use either method, but I favor this new idea right now. What do you think?

    The other alternative is to read source lines from one edit dialog and write the conversions to another dialog.
    Could go either way. gConcordance() tries to keep the VB & PB source lines separate while working on them.

    If you like the idea of putting the entire VB source file into a GLOBAL array, I believe we can dispense with the gConcordance() array altogether. If we keep it gConcordance() is going to use a LOT of memory.


    ...
    if the visual aspect of the forms is an important part of the conversion process and if it doesn't reliably work ALL the time the user is going to get frustrated and probably curse the converter, PowerBASIC, etc.
    It's a shame, but your absolutely correct on this point.

    In order to do the job it looks like to me that it would require a combination of several separate tools to get the job done and I think this would be unacceptable to a new user. They would want all the conversion functionality they need under one hood.
    I'm currently scouring the forums for code and tools. I going to adapt any useful public domain code and forum contributor code with permissions.



    ...
    didn't look like it was overly impossible to write some code to convert the VB forms to PB. One of the aspects of this conversion that interested me was the conversion of the VB events, Button_Click() and Textbox_Change() for example, to its equivalent PB code.

    I could see where a new PB user may want to preserve the original VB event code simply to keep the flavor of the VB application in PB. Perhaps this feature could be a user defined option that could be turned off as the user becomes more familiar with PB CallBacks and Windows Messages (which still confuses me to no end).
    Some while back we talked about naming conventions. If I remember, part of that discussion (which included underscores) was to make the PB function names as close as possible to the function/method/event names used in the original. Hopefully doing this will preserve some of that flavor.


    Concerning the tool for commenting out unused procedures, I think it is important to have such a process because, as you know, VB includes all source code from a code module in the final application so there will undoubtedly be a lot of VB source code we may not have to convert.

    It just so happens I do have such a beast, however, it is a memory hog, but I think it could be rewritten to use a random access file without degrading performance too much. It was based on the PBCodec app that Lance, Borje, and Scott Slater and a host of others contributed to. The difference in my implementation is that it actually outputs the revised source code. I set up another directory called \COMPRESS to hold this revised source so it looks like we will have another subdirectory to add to our processing options.
    wow! Great Minds run along parrallel paths. I was looking at that code this morning. It is the most promising I've found so far. If you've already tweaked a bit, please share. Maybe we can integrate it in short order.

    Leave a comment:


  • Rodney Hicks
    replied
    Is it not our job as converter gods of creation to find a way to tie all the aspects of the VB, in this case a textbox and a button, together. Can we not access the ShowDialog1 procedure(others as created by PBForms) and find the textbox features, then the button features from the other VB files and put them in their appropriate places in the ShowDialogx procedure or the Callback function.

    What these questions are leading up to is that if we use PBForms for the first stage and convert the files via the converter it would save us trying to tie PBForms(or its alternative) functionality with WinSpy functionality and any other program's functionality. I recognize that there are a lot of programs(tools) to do a lot of the things that we need done but trying to get them to work together might be just as big a problem as our original project.

    I am trying to ascertain if we are better off just getting the basics working, then adding a step here, a step there, etc. until it becomes time for a rewrite.

    We already have here in this forum a lot of capability, but we don't have it together in one place so that we can just add a new feature as we develop it.

    If we were to all stand back and take a look at the forest, I think that we might see a beautiful sight, even though not one of us is satisfied with it yet. With an edge trimmer and a bulldozer we could make the forest presentable as a wildlife preserve(VBers being what they are). We add human creature comforts a bit at a time.
    Last edited by Rodney Hicks; 16 Sep 2008, 02:42 PM. Reason: bad grammar

    Leave a comment:


  • StanHelton
    replied
    Originally posted by Rodney Hicks View Post
    ...
    When you create a form in VB with say a textbox and a button, adding whatever features you wish, VB must create all the files simultaneously. That is the frm file and whatever other file that handles all the features that aren't included in the frm file.
    ...
    Is this not a correct analysis?
    That's pretty much it. And then vb2pb has to find the correct Button1_Click() to plug into the correct SELECT CASE %WM_COMMAND spot as a function call.

    This is the first of a few questions of this nature.
    Keep 'em coming. This rapidly turning into a question driven project.

    Leave a comment:


  • Rodney Hicks
    replied
    Not being a VB user, and thus not having VB to test this with, but thinking maybe that possibly that it could be that sorta ....

    When you create a form in VB with say a textbox and a button, adding whatever features you wish, VB must create all the files simultaneously. That is the frm file and whatever other file that handles all the features that aren't included in the frm file.

    PBForms only access the frm files and creates a skeleton for the project, then each of the features that VB relegates to another file have to be added to the output file in the appropriate places. The frm file may give the location and size of the textbox, but some other file will add the styles, and yet another file will add the manipulations, and yet another file will add the headaches.

    Is this not a correct analysis?
    This is the first of a few questions of this nature.

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

    So, yes, line-by-line. There is enough tracking built into the Tokenizer to locate code snippets within the proper source code structures. The only part of the WholeFile idea we need to keep for now is the initial scan for the Tokenizer to locate and track everything.
    When the Tokenizer scans the file and locates its desired targets are those locations cast in concrete? Can they be moved? My reason for asking this is if we intend to comment out the VB portions of the code and insert the PB conversions in the same edit dialog then the total number of lines in the copy of the source file will change and thus destroy the original target locations found by the Tokenizer. Could we have a message to direct the Tokenizer to rescan from the next legitimate VB source line forward?

    The other alternative is to read source lines from one edit dialog and write the conversions to another dialog.

    I noticed Wayne's comments also. Actually, the skeleton is in there 95-99% of the time, but it is taxing my brain to track all the code moving around to get a smooth conversion. It's beginning to look like it could turn out easier to build our own DDT converter/designer.
    I tend to agree with you. IMO the visual aspect of the forms is an important part of the conversion process and if it doesn't reliably work ALL the time the user is going to get frustrated and probably curse the converter, PowerBASIC, etc.

    PBForms may be problematic, after all. I'm having some difficulty using it in the code. I've been looking at WinSpy. It produces some very interesting code snippets, but I'm not sure it will do the job either.
    In order to do the job it looks like to me that it would require a combination of several separate tools to get the job done and I think this would be unacceptable to a new user. They would want all the conversion functionality they need under one hood.

    I find myself hoping Mike will come up with an alternative soon.
    Me too.

    I actually stayed up until about 1:30 in the morning looking at some of the .FRM files from a couple of VB projects of my own. It didn't look like it was overly impossible to write some code to convert the VB forms to PB. One of the aspects of this conversion that interested me was the conversion of the VB events, Button_Click() and Textbox_Change() for example, to its equivalent PB code.

    I could see where a new PB user may want to preserve the original VB event code simply to keep the flavor of the VB application in PB. Perhaps this feature could be a user defined option that could be turned off as the user becomes more familiar with PB CallBacks and Windows Messages (which still confuses me to no end).

    Concerning the tool for commenting out unused procedures, I think it is important to have such a process because, as you know, VB includes all source code from a code module in the final application so there will undoubtedly be a lot of VB source code we may not have to convert.

    It just so happens I do have such a beast, however, it is a memory hog, but I think it could be rewritten to use a random access file without degrading performance too much. It was based on the PBCodec app that Lance, Borje, and Scott Slater and a host of others contributed to. The difference in my implementation is that it actually outputs the revised source code. I set up another directory called \COMPRESS to hold this revised source so it looks like we will have another subdirectory to add to our processing options.

    I don't use inclean, but it looks nice, if we can integrate it.
    A good utility, you should try it. As an alternative Jose Roca has created wrapper procedures for the Common dialog and Common control include files which are available from his web site, you have to be a registered member to access them though. Well worth the effort IMO.

    Leave a comment:


  • StanHelton
    replied
    Originally posted by StanHelton View Post
    ...
    What do you think about the Tokenizer holding all the converted code for a single session in the gConcordance() array?
    ...
    Originally posted by John R. Heathcote View Post
    ...
    If we do decide to keep this functionality the question we have to ask is, what is the direct benefit to the user?
    ...
    Second look at this issue. I agree with dropping the WholeFile option for now. Limited benefit and it would be a memory hog the way I set it up initially. I can look at this for the next iteration if feedback justifies it.

    So, yes, line-by-line. There is enough tracking built into the Tokenizer to locate code snippets within the proper source code structures. The only part of the WholeFile idea we need to keep for now is the initial scan for the Tokenizer to locate and track everything.

    Leave a comment:


  • StanHelton
    replied
    Originally posted by John R. Heathcote View Post
    ...
    I think this could be a user defined option. I can see where a smaller VB project might benefit from this approach. Displaying the converted information would have to be handled differently ...

    ,,, don't see any practical way to mix the two conversion input scenarios. Not that it couldn't be done, but I think we have to keep things practical.
    Good points. We'll stick to line-by-line for now. Maybe whole projects next iteration.

    I tend to agree with you here. Let the editor handle the file display and maintenance stuff and let the Tokenizer handle the all important conversion stuff. I wouldn't get rid of this code ...
    Done. Bracketed with #IF/#ENDIF.

    I know we have talked about using PBForms as a method of converting VB forms, however, the observations Wayne made concerning his conversion tests disturbs me. The fact that PBForms apparently "left out" so many individual parts of the original VB form leads me to think that maybe PBForms would not be a good solution after all. I say this from the perspective of a new user attempting to convert a VB program, running it through our converter and ending up with trashed/incomplete dialog boxes. The user is expecting the conversion to work. If it doesn't then what does the new user do to solve the problem?
    I noticed Wayne's comments also. Actually, the skeleton is in there 95-99% of the time, but it is taxing my brain to track all the code moving around to get a smooth conversion. It's beginning to look like it could turn out easier to build our own DDT converter/designer.

    PBForms may be problematic, after all. I'm having some difficulty using it in the code. I've been looking at WinSpy. It produces some very interesting code snippets, but I'm not sure it will do the job either.

    I find myself hoping Mike will come up with an alternative soon.

    Some questions I thought of as I was typing...

    How do feel about including a "tool" that looks for and comments out unused procedures?
    Yes. Has anybody in the community posted such a thing? I know there were several for PB/DOS.

    Should we include tools like Inclean?
    I don't use inclean, but it looks nice, if we can integrate it.

    A Message Box designer?
    Visual designer? I guess it would have to be. I haven't thought about this possibility before. This brings me back to my struggle getting PBForms to jump through hoops.

    Should we provide a link to POFFS?
    Yes. The help is likely to be rudimentary in this edition. Links to POFFS and PB Forums should be provided.

    A link to PBWinSpy?
    I'm evaluating this as a possible aid to the forms translation issue.

    Etc., etc., etc.

    Maybe not in Version 1, but certainly in subsequent versions.
    I think we should tie the help and references very tightly into the resources available here on the forums and any 3rd party sites that look good; Jose Roca's site comes to mind. Third party sites and tools should be part of the help/reference system.

    Bubbling in the darker regions of my brain is the possibility of including add-ins. But I want to finish the basic conversion engine before going too far afield.

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

    What do you think about the Tokenizer holding all the converted code for a single session in the gConcordance() array?
    I think this could be a user defined option. I can see where a smaller VB project might benefit from this approach. Displaying the converted information would have to be handled differently than the line by line process I'm using now. I would envision that the contents of the entire gConcordance() array could be converted to a string and then loaded into a new MDI editor form. Technically this would actually be easier than displaying converted code line by line. Think of it as loading a file after you've selected it from the OPENFILE dialog box.

    If we do decide to keep this functionality the question we have to ask is, what is the direct benefit to the user?

    On a larger project the user might want to have more control over file I/O of the individual conversion files, I know I would want to have this capability, so I would opt for the line by line conversion/display.

    On the down side, the user would have to either let the Tokenizer hold the entire converted code and then display, or allow the editor to feed the Tokenizer source code lines. I really don't see any practical way to mix the two conversion input scenarios. Not that it couldn't be done, but I think we have to keep things practical.

    This was my original design, but now I'm thinking it would be better for the Editor to maintain in the file I/O.
    I tend to agree with you here. Let the editor handle the file display and maintenance stuff and let the Tokenizer handle the all important conversion stuff. I wouldn't get rid of this code, I would keep it in the Tokenizer source, but maybe comment it out so it doesn't create unused procedures in the EXE.

    I know we have talked about using PBForms as a method of converting VB forms, however, the observations Wayne made concerning his conversion tests disturbs me. The fact that PBForms apparently "left out" so many individual parts of the original VB form leads me to think that maybe PBForms would not be a good solution after all. I say this from the perspective of a new user attempting to convert a VB program, running it through our converter and ending up with trashed/incomplete dialog boxes. The user is expecting the conversion to work. If it doesn't then what does the new user do to solve the problem?

    Some questions I thought of as I was typing...

    How do feel about including a "tool" that looks for and comments out unused procedures?

    Should we include tools like Inclean?

    A Message Box designer?

    Should we provide a link to POFFS?

    A link to PBWinSpy?

    PBForms?

    Etc., etc., etc.

    Maybe not in Version 1, but certainly in subsequent versions.

    Leave a comment:


  • StanHelton
    replied
    John,

    What do you think about the Tokenizer holding all the converted code for a single session in the gConcordance() array? This was my original design, but now I'm thinking it would be better for the Editor to maintain in the file I/O.

    Let me know.

    Stan

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

    Good enough. I'll be satisfied with the FeedMe messages then.
    I think we need one more Tokenizer return message, a "%NoChange" message. This message would be passed back to inform the editor that the input source line was not changed/no conversion performed, or was necessary. This will help eliminate the multitude of updated source code lines the editor would have to track and redisplay.

    Thinking about it as I type ... probably not worth the effort until we're sure we can handle the big projects.
    I've been giving the large project issue some thought myself, and the more I think about it the deeper I get into a never ending file maintenance logic issue. I think we will eventually be able to handle large projects, I just don't quite know how to do it yet, may have to spend more time in the shower to solve this problem. Currently, I'm leaning towards something like Lynx or the Project Stuff in the SED editor as a desing/functionality option, but not sure.

    Any speed advantage? It would have to be significant to be worthwhile.
    It wouldn't take too long to strip out the special Scintilla characters and insert the ones the Tokenizer needs. I was thinking more about the added functionality option than speed.

    I'm thinking that by passing the code line-by-line like we talked about, the Editor could allow the user to watch the progress, fast as it may be. Who knows; somebody may want the option of pausing for a cup of coffee or something.
    Excellent suggestion. The "Pause" factor could be a user defined option.

    Leave a comment:


  • StanHelton
    replied
    John,

    Originally posted by John R. Heathcote View Post
    ...
    If we want to show the progress of the conversion we can do this from the editor by comparing the lines read against the total file text size. Not exact, but would be a close approximation.
    Good enough. I'll be satisfied with the FeedMe messages then.


    Not trying to muddy the waters here, but we can still do this, if there is an advantage and need to do it. Perhaps as a user defined option? I was approaching the problem simply from the editor point of view, however, I was guilty of not thinking outside the box.
    The only real advantage would be that the Tokenizer could do the initial info scan asynchronously. Not sure that is useful at this point, but something we can add later. Thinking about it as I type ... probably not worth the effort until we're sure we can handle the big projects.

    The editor can pass the entire contents of the edit control as a string to the Tokenizer if need be, although it has not been programmed to do this functionality yet. To pass the entire file would not be any more difficult than what is necessary to save the editor contents to a file and I have that functionality already coded. The only thing that would be left to do is to cannibalize the save code and replace the $CR$NUL with $CRLF before we send the string to the Tokenizer. Very simple.
    Any speed advantage? It would have to be significant to be worthwhile. I'm thinking that by passing the code line-by-line like we talked about, the Editor could allow the user to watch the progress, fast as it may be. Who knows; somebody may want the option of pausing for a cup of coffee or something.

    Always trying to keep on the same page as the Big Kahuna.
    hmmmm....

    "Which way did they go? Please tell me for I am their leader and I must follow them."

    Stan

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

    I was trying to figure out a way to send a progress percent number back to the editor...
    If we want to show the progress of the conversion we can do this from the editor by comparing the lines read against the total file text size. Not exact, but would be a close approximation.

    My conceptual difficulty is that when I set this up originally I was thinking of reading a file. The idea that the Editor handles the file I/O is forcing me to change things for the new concept.
    Not trying to muddy the waters here, but we can still do this, if there is an advantage and need to do it. Perhaps as a user defined option? I was approaching the problem simply from the editor point of view, however, I was guilty of not thinking outside the box.

    The editor can pass the entire contents of the edit control as a string to the Tokenizer if need be, although it has not been programmed to do this functionality yet. To pass the entire file would not be any more difficult than what is necessary to save the editor contents to a file and I have that functionality already coded. The only thing that would be left to do is to cannibalize the save code and replace the $CR$NUL with $CRLF before we send the string to the Tokenizer. Very simple.

    Always trying to keep on the same page as the Big Kahuna.

    Leave a comment:


  • StanHelton
    replied
    Originally posted by John R. Heathcote View Post
    Stan,

    You proposed the following equates:

    Code:
    %SendOneLine
    %Wait_ConvertingLine
    
    %StructureBeginningDetected
    %StructureEndingDetected
    
    %Wait_ConvertingStructure
    
    %ConversionComplete
    Is it necessary to have the %Wait_xxxxxx equates? These equates would be necessary if we are running the Tokenizer asynchronously, however, I was assuming that the Tokenizer would be run synchronously with the editor, but it is quite possible I am missing something here.
    No, you are correct. We run synchronously. I was trying to figure out a way to send a progress percent number back to the editor and ended up (late one night) punting. These equates are not necessary.


    ...
    Does the above get into the synchronous/asynchronous issue? If we run the Tokenizer synchronously why can't the Tokenizer convert lines on the fly? ...
    You're asking the right questions. On the fly is fine. Focusing on the line-by-line process with theTokenizer calling for more code when needed makes this happen. My conceptual difficulty is that when I set this up originally I was thinking of reading a file. The idea that the Editor handles the file I/O is forcing me to change things for the new concept.

    Keep asking questions, especially when I say something that doesn't add up. It helps me to catch all the details before they become problems.


    Okay. I think we're good then.

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

    You proposed the following equates:

    Code:
    %SendOneLine
    %Wait_ConvertingLine
    
    %StructureBeginningDetected
    %StructureEndingDetected
    
    %Wait_ConvertingStructure
    
    %ConversionComplete
    Is it necessary to have the %Wait_xxxxxx equates? These equates would be necessary if we are running the Tokenizer asynchronously, however, I was assuming that the Tokenizer would be run synchronously with the editor, but it is quite possible I am missing something here.

    Editor always sends one line at a time. Tokenizer notifies Editor that another line is needed. Conversion is line by line unless Tokenizer decides it needs more lines to make the conversion.
    OK, sounds good.

    First pass through code is where the Tokenize identifies variables, classes, functions, et al, so before the user is allowed to select which part of a file to convert (Line, procedure, class, whatever), it needs to scan the entire active file. No conversion on this pass, just gathering info.
    A scan pass is doable. I will implement some skeleton code to do this in the editor.

    Once file info is gathered from the Editor one line at a time, the Editor/user can decide which lines to convert. Tokenizer sends %IsReady while waiting, %SendOneLine when needed, and %ConversionComplete when finished.
    Does the above get into the synchronous/asynchronous issue? If we run the Tokenizer synchronously why can't the Tokenizer convert lines on the fly? I guess I just don't understand the processing scenario here, sorry for being so (obnoxiously?) dense.

    When a structure is identified by Start/End lines, Tokenizer will ask for enough lines one at a time to complete the process for the entire structure. During conversion the %Wait_ConvertingLine or %Wait_ConvertingStructure message will be queued.
    Sounds good to me.

    Leave a comment:


  • StanHelton
    replied
    John,

    Originally posted by John R. Heathcote View Post
    ...
    So if the Tokenizer needs additional source code lines the editor needs to know how many to send. The only way to do that is for the Tokenizer to tell the editor to send additional source code lines.
    Doh. Sometime soon I'm going to learn English. Okay I understand now. How about the editor sends 1 line at a time and we use the following, all as INFO messages:
    Code:
    %SendOneLine
    %Wait_ConvertingLine
    
    %StructureBeginningDetected
    %StructureEndingDetected
    
    %Wait_ConvertingStructure
    
    %ConversionComplete
    Editor always sends one line at a time. Tokenizer notifies Editor that another line is needed. Conversion is line by line unless Tokenizer decides it needs more lines to make the conversion.

    First pass through code is where the Tokenize identifies variables, classes, functions, et al, so before the user is allowed to select which part of a file to convert (Line, procedure, class, whatever), it needs to scan the entire active file. No conversion on this pass, just gathering info.

    Once file info is gathered from the Editor one line at a time, the Editor/user can decide which lines to convert. Tokenizer sends %IsReady while waiting, %SendOneLine when needed, and %ConversionComplete when finished.

    When a structure is identified by Start/End lines, Tokenizer will ask for enough lines one at a time to complete the process for the entire structure. During conversion the %Wait_ConvertingLine or %Wait_ConvertingStructure message will be queued.

    Summary:
    Tokenizer decides when and how many lines it needs.
    Editor sends one line at a time.
    Tokenizer sends Wait_message while working
    Tokenizer sends %ConversionComplete when finished.

    When Tokenizer %IsReady, it is waiting for the Editor to send a first line of code. Based on the first line and the info gathered on the first pass, Tokenizer will determine how many lines are to be sent one at a time.

    Editor always passes one, and only one, line of code for each Tokenizer request.

    Leave a comment:


  • John R. Heathcote
    replied
    Stan,

    The gVbCodeBlock is a dynamic string so 1 line or 100, no difference to the Tokenizer. The message back to the Editor will be %IsFinished -- current gVbCodeBlock now has an equivalent gPbCodeBlock.
    I guess I didn't format my question properly, or clearly.

    Since the Tokenizer is the process performing the actual conversion I think it should be in charge to determine how many VB source code lines it needs for any conversion task. The editor can pass source code lines, but it is just text, the editor has no context at this point, it hasn't been programmed (yet?) to decipher a FOR/NEXT code block from an IF/END IF statement. If we decide to put such intelligence in the editor then what would be the purpose of the Tokenizer? Assuming we are going to leave things as they are, the intelligence lies with the Tokenizer. So if the Tokenizer needs additional source code lines the editor needs to know how many to send. The only way to do that is for the Tokenizer to tell the editor to send additional source code lines.

    Leave a comment:

Working...
X