I sent my reply to Mark G instead of the list - sorry. Anyhow, that is now
outdated...
Actually, I think I may have got this wrong. I always believed that Mark
had disabled the legacy methods, but playing around with my install of
4.2.3 I can mix the old methods with the new.
So, maybe it will be alright to distribute 4.2.4 with 5.0.0.
Jon
On Tue, 28 Aug 2018 at 22:32, Jon Wolfers <sahana...@gmail.com> wrote:
> Hi Mark,
>
> I'm sure it could be made to work, but it is a bit of a daunting task
> because the two collaborators who designed the changes are both dead and
> the differences are big and the user base is startlingly small.
>
> If it were just a case of substituting one method name for another then a
> wrapper or even a conversion tool could be produced, but some of the tasks
> that used to be handled by methods, now require one to get 'helper' class
> instances.
>
> ooDialog is big and I don't know whether anyone is familiar with all of
> it, both old and new (I have used maybe 80% of the old ooDIalog and maybe
> 50% of the new).
>
> on 5th April 2007 Mark Wrote to me:
>
>> I am interested in ooDialog and have slowly been getting acquainted with
>> it. There are several things I want to do (along with fix the open bugs
>> and work on some of the RFEs.) I have discovered in the past week / 10
>> days that there is a fair amount of code that was used to try and give
>> ooDialog on Windows 3.0 and 3.1 a better look, that is now hindering
>> things on XP. Since ooRexx can't run on Windows 3.1 anymore (I don't
>> think) that stuff needs to be removed. So, the sort of big areas I am
>> interested in are:
>>
>> 1.) Bring ooDialog up to date with Windows XP
>>
>> 2.) Add in some (most?) of the new controls that you have in XP. For
>> instance, it would be nice to have the RichEdit control. That would allow
>> you to display hi-lighted / colored text much easier in your dialogs.
>>
>> 3.) Fix the .rc file parsing so that it works with the major resource
>> editors / add examples and better documentation on how to use ooDialog with
>> resource editors, and where you can get resource editors.
>>
>> The one thing I am a little undecided on, is that for 4.0, it might be a
>> good idea to move to using wxWidgets and develop a cross-platform GUI
>> interface for ooRexx. Maybe the time would be better spent working on
>> that, rather than on improving ooDialog. But, ooDialog works and works
>> now. <grin> There is that old saying of a bird in the hand is worth 2 in
>> the bush.
>
>
> Over 1000 commits, just over 7 years later he got it to the point it is
> before being unexpectedly hospitalised.
>
> Oliver Sims worked on the early GUI systems, if I understood what he said
> correctly, he built his own OO framework before OO languages were available
> to support his work. He critiqued ooDialog as not being suitable for large
> scale developments and did a lot of work (which can be seen in the ooDialog
> user guide) envisaging what was needed and providing a lot of it. Oliver
> sparked Mark off to go in some exciting new directions. Sadly Oliver had
> Mesothelioma and did not survive Mark by long.
>
> I think (and I could be wrong about this) a wrapper would be more work
> than allowing legacy users an opportunity to remain with an earlier version.
>
> Hope this helps and is interesting too.
>
> Jon
>
> On Tue, 28 Aug 2018 at 22:02, Mark L. Gaubatz <mgaub...@groupgw.com>
> wrote:
>
>> Jon:
>>
>> On a prior contract project during the design stage and before the
>> contract was canceled, the project architect and I were tossing around the
>> idea of writing a legacy wrapper package to permit the 5+ million lines of
>> existing code to work with newer code. Would such an approach work with
>> ooDialog?
>>
>> Mark L. Gaubatz
>>
>> On 08/28/2018 01:49 PM, Jon Wolfers wrote:
>>
>> Hi Erich and Rick,
>>
>> I'm not sure that this is a good idea.
>>
>> Mark & Oliver we're overhauling ooDialog, and as I recall, Mark
>> deprecated a lot of what most users would consider basic ooDialog
>> fuctionality in the latest release or perhaps last few releases.
>>
>> This means that if my memory serves me right, at the point that Mark was
>> no longer able to work:
>>
>> 1) A lot of written code will not run with the newest version
>> 2) The overhaul was not complete, so there may be bits of old and bits of
>> new in there
>> 3) I'm not sure how complete the documentation is
>>
>> I think it might be safer if we can do it to work out a way that users
>> can choose a version of ooDialog to use with 5.0.0, because the changes
>> needed to legacy code were not small.
>>
>> Using a ComboBox control as an example the 'new' userdialog class had
>> methods named like 'CreateComboBox' where the old userdialog class had
>> methods named like 'addComboBox'. The old methods would not run in the new
>> version. Proxies were obtained in the old userdialog with methods name
>> 'getComboBox' and in the new userdialog with methods named like
>> 'newComboBox'.
>>
>> A considerable number of helper classes were introduced where the
>> previous functionality had been 'under the covers'.
>>
>> All in all,it increased the power of ooDialog and ironed out a lot of
>> historic irregularities, but migration required some considerable work.
>>
>> I'm not sure without checking at which version the change happened, but I
>> will try to research it over the next couple of days and get back to you on
>> this.
>>
>> Jon
>>
>>
>> On Tue, 28 Aug 2018 at 21:23, Rick McGuire <object.r...@gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Aug 28, 2018 at 3:26 PM Erich Steinböck <
>>> erich.steinbo...@gmail.com> wrote:
>>>
>>>> I'm thinking of integrating the latest standalone ooDialog code into
>>>> main/trunk for 5.0.
>>>>
>>>> ooDialog standalone code (which should be 4.2.4 with some delta to the
>>>> last released 4.2.4 standalone-preview) has not yet been branched and is
>>>> still nmake-based (not CMake). I do not intend to convert / maintain it,
>>>> but I'm thinking of merging the 4.2.4 trunk back into main/trunk. ooDialog
>>>> docs in main/trunk are already at the 4.2.4 level, while main/trunk
>>>> ooDialog code is still at 4.2.3.
>>>>
>>>
>>> I think this is a good idea.
>>>
>>>
>>>>
>>>> Merging will have to be done carefully, because different changes seem
>>>> to have been made to both trunks.
>>>>
>>>> What's the suggested SVN command to merge back ooDialog-standalone code
>>>> into main/trunk, keeping its SVN revision history?
>>>>
>>>
>>> I used this guide when I did the merge:
>>>
>>> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html
>>>
>>> The first step of merging changes back into the trunk seemed to miss
>>> updates on some files, and the pattern made no sense, such as missing
>>> portions of individual commits. I never figured out what the problem was,
>>> but I had to fix up a lot of things manually. I found it useful to do an
>>> SVN diff between the two branches and take a close look at the deltas to
>>> make sure that nothing was getting backed out from the trunk version when
>>> the merge happened. It helped that I was familiar with all of the changes,
>>> not a luxury we have with the oodialog code.
>>>
>>> I don't know if this is a factor or not, but that branch is very old and
>>> the newer SVN branch merge features might predate that branch getting
>>> taken, so it might not have all of the information used for tracking the
>>> merges. It might be impossible to keep the revision history.
>>>
>>> There's a lot of information available by doing "svn help merge".
>>>
>>>
>>>>
>>>> Rick, you said SVN gave you fits, when you merged the "address with"
>>>> changes back into trunk .. what are the pitfalls to avoid?
>>>>
>>>
>>> SVN diff is your friend for double checking that something is not
>>> accidentally backed of. Generate an SVN diff for both branches so you know
>>> what the state of everything is before you start merging, then use that
>>> information to double check everything before committing.
>>>
>>> Rick
>>>
>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Oorexx-devel mailing list
>>>> Oorexx-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Oorexx-devel mailing list
>>> Oorexx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Oorexx-devel mailing
>> listOorexx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
