How to Merge Updated Class with Existing Class in IDE

[Dave_OBrien]

So now I have got a reasonable grasp on the CalendarTimeChooser, and really have to say it is an amazing ‘utility’ and think this is going to be a part of many future projects - hats off to the author, Mike Cotrone

Thanks Mike - stunning.

But what happens when there are changes ?

It is inevitable that something in the class could change at some time in the future. But I have already added code to, for example, the 4_Cal-Time Chooser Window … DateTimeWindow … Controls … Finished_Button … Action Event.

So when a new / updated version of the class is released, what is the best way to ensure that I do not lose the changes that I have made ?

Is there a standard class update protocol that should be followed ?

Asking now before I go coding crazy and create my own nightmare.

[Mike_Cotrone]

Knowing that the “Calendar/Time Chooser project” is a set of Folders which contain custom classes, containers, etc. I would normally keep the project as is using my git source control (Source Tree). Source Tree will automatically tell you for example when I make additional commits ie. new version. Since this isn’t a compiled plugin it is very hard to really truly “version” it.

My goal for this project is to make major commits to it which would in turn be a “version” like system as I am already trying to do. I commit to you and the Xojo community this will be the case so you would drop clone the new “version”, delete my old folders, and drop in the replacement version folders. Try to keep your Custom Integrated front end (ie. push button) separated a bit (by way of folders) to make this process smooth. I personally do this with my projects and has worked well for me.

Any other advice from the community would very much be appreciated on this.

Thanks!
Mike

[Tim_Hare]

Dave, if you’re making extensive changes to the class, then you’re using it wrong. Sorry to say. From your other posts, I’d say that you need to add events to your pushbutton class and use the events in Mike’s class to call your events. That allows you to pass info along to the window. Rather than butcher Mike’s class, try to take a more OOP approach.

[Dave_OBrien]

Thanks Mike and Tim

I have already moved your 6 code folders in to a ‘CalTimeClass’ folder in my IDE - just keeps it neater for me.

@190685:@Tim Hare

Dave, if you’re making extensive changes to the class, then you’re using it wrong. Sorry to say. From your other posts, I’d say that you need to add events to your pushbutton class and use the events in Mike’s class to call your events. That allows you to pass info along to the window. Rather than butcher Mike’s class, try to take a more OOP approach.

Tim, I agree with you 100%, and since I ‘discovered’ the trick of hiding ( not closing ) the Chooser window so that I can still access the SelectedDate property, I have been able to revert back to the stock standard class as I downloaded it, with the exception of 2 items.

There are 2 places where, as far as I can see, the ‘virgin’ class requires changes after adding to the IDE.

These are the Cancel_Button Action, and the Finished_Button Action events. These need code so that the user can do whatever the user wants with them - great - but any code added by the user will break when an updated version of the class is downloaded and added to the IDE, replacing the existing modified class.

So if Mike is open to suggestions, may I please be so forward to request / suggest something along the lines of :

Add 2 properties to the class :
GoActive As Boolean = False
GoButtonSelected as Integer = 0

Modify the 2 existing buttons so that it is possible for users to use the chooser without having to make any changes in the class :

// for Finished_Button
Sub Action()
  GoButtonSelected = 1
  GoActive = False
  me.window.Hide
End Sub

// for Cancel_Button
Sub Action()
  GoButtonSelected = 2
  GoActive = False
  me.window.hide
End Sub

This way, majority of the users can work with the class unchanged. The parent window where the instance is created can access the properties of the Chooser instance to get the :
SelectedDate
SelectedTime
GoActive ( set to true when opening the Chooser in the button action event, false = Chooser window has been closed )
GoButtonSelected ( 0 = Chooser window closed - no button clicked, 1 = Select Clicked, 2 = Cancel Clicked )

Just my 2c. Please ignore if a bad idea.

[Tim_Hare]

@190691:@Dave OBrien

There are 2 places where, as far as I can see, the ‘virgin’ class requires changes after adding to the IDE.

You’re still not getting it. You should add code to your own subclass, not to Mike’s class. Your subclass should respond to Mike’s events by raising its own events. The window can then respond to your events and do whatever is appropriate in the context of the actual implementation.

[Mike_Cotrone]

To add to what Tim is saying the main reason I wrote the demo window in an OOP way was to allow an ease of detachment, however you still utilize the classes I wrote using the events that I provide. You can tap those like Tim is saying above which is honestly the easiest way and the goal I had when creating this project. the ultimate goal was to allow the coder to worry about the “front end/window implementation ie. replacing the demo window”, but not having to do anything beyond that.

[Dave_OBrien]

@190706:@Tim Hare

You’re still not getting it. You should add code to your own subclass, not to Mike’s class. Your subclass should respond to Mike’s events by raising its own events. The window can then respond to your events and do whatever is appropriate in the context of the actual implementation.

Hi Tim

Maybe I am not getting it. Quite possible and highly probable.

My point is that if I look at the latest class I downloaded and added to my IDE, the following :

4_Cal-Time Chooser Window … DateTimeWindow … Controls … Finished_Button …
contains the following in the Action Event :

MsgBox "Thank you for using our project!"

Now I have to admit that I am very very new to this type of code, but for the life of me I can not see where to change or set anything in the instance of the class, from outside the class when I create the instance, that would change the functionality of that Action Event.

What am I missing ?

My suggestion was to add something to the class that removes the need for the user to manually modify the class for this Action Event, and therefore avoid breaking the project when updating the class.

[Mike_Cotrone]

I am sure Tim was referencing the other posts you had and I was the same. However my first reply on this thread talks about what you are asking for open source project “up keep” so to speak.

I do the same thing that you are asking myself personally. Any time I make significant changes to the Calendar Time Chooser project with one of my apps i then immediately open the open source repo and implement those same changes. I then bump the version with a git tag and commit the changes.

The difference is at any time I can delete the classes/container Folders from other projects that use the “older” implementation of Calendar Time Chooser and replace them with the new updates folders. It is clean and works well. I do this for Retinakit, MacOSLib, etc.

You just can’t tangle your custom code within my classes to Tim’s points. Does that help?

[Dave_OBrien]

@190707:@Mike Cotrone

MsgBox “Thank you for using our project!”

Thanks Mike.

I agree that Tim, and yourself, would likely have taken my other posts into consideration when replying to this one. Fortunately I have been able to basically remove all the mods I made ( hacked due to my own lack of knowledge about classes ) in the class and revert back to your code ( phew ! )

While I fully appreciate everything you have done, how can : MsgBox “Thank you for using our project!” in the class NOT require the class to be manually changed ?

Please understand that I am not trying to nit-pick or be difficult, but if the goal is to aim for a ‘plug n play’ style for a class update, surely this could be modified to give majority of users a way to work with the unmodified class ?

[Mike_Cotrone]

[quote=190713:@Dave OBrien]Thanks Mike.

I agree that Tim, and yourself, would likely have taken my other posts into consideration when replying to this one. Fortunately I have been able to basically remove all the mods I made ( hacked due to my own lack of knowledge about classes ) in the class and revert back to your code ( phew ! )

While I fully appreciate everything you have done, how can : MsgBox “Thank you for using our project!” in the class NOT require the class to be manually changed ?

Please understand that I am not trying to nit-pick or be difficult, but if the goal is to aim for a ‘plug n play’ style for a class update, surely this could be modified to give majority of users a way to work with the unmodified class ?[/quote]
Dave that is just a simple msgbox to announce that you need to implement behavior to this project.

This is done on the DateTime Window and the “submit” button is just a button that sits atop of this window. There is no class work done here at all. I think maybe the terminology may be whats confusing this a bit perhaps.

The DateTimeWindow was designed to be dynamically instantiated, but I still intended for the coder to implement this using their needs for their software. This again is what I consider the “Front End GUI” that uses my classes behind it. The Submit Button was designed to be an a button with the action event as the source for you to implement your behavior of the classes.

For example in the SubmitButton -->Action event you could have a method that is called to set all of the calendar time chooser user options which forms the implementation.

Does that make sense?

[Mike_Cotrone]

[quote=190708:@Dave OBrien]Hi Tim

Maybe I am not getting it. Quite possible and highly probable.

My point is that if I look at the latest class I downloaded and added to my IDE, the following :

4_Cal-Time Chooser Window … DateTimeWindow … Controls … Finished_Button …
contains the following in the Action Event :

MsgBox "Thank you for using our project!"

Now I have to admit that I am very very new to this type of code, but for the life of me I can not see where to change or set anything in the instance of the class, from outside the class when I create the instance, that would change the functionality of that Action Event.

What am I missing ?

My suggestion was to add something to the class that removes the need for the user to manually modify the class for this Action Event, and therefore avoid breaking the project when updating the class.[/quote]

Dave this is a button that sits on top of a window. Technically its an object class, but its a class type of button. Terminology may be the difference here.

[Mike_Cotrone]

[quote=190691:@Dave OBrien]Thanks Mike and Tim

I have already moved your 6 code folders in to a ‘CalTimeClass’ folder in my IDE - just keeps it neater for me.

Tim, I agree with you 100%, and since I ‘discovered’ the trick of hiding ( not closing ) the Chooser window so that I can still access the SelectedDate property, I have been able to revert back to the stock standard class as I downloaded it, with the exception of 2 items.

There are 2 places where, as far as I can see, the ‘virgin’ class requires changes after adding to the IDE.

These are the Cancel_Button Action, and the Finished_Button Action events. These need code so that the user can do whatever the user wants with them - great - but any code added by the user will break when an updated version of the class is downloaded and added to the IDE, replacing the existing modified class.

So if Mike is open to suggestions, may I please be so forward to request / suggest something along the lines of :

Add 2 properties to the class :
GoActive As Boolean = False
GoButtonSelected as Integer = 0

[quote]
Modify the 2 existing buttons so that it is possible for users to use the chooser without having to make any changes in the class :

// for Finished_Button
Sub Action()
  GoButtonSelected = 1
  GoActive = False
  me.window.Hide
End Sub

// for Cancel_Button
Sub Action()
  GoButtonSelected = 2
  GoActive = False
  me.window.hide
End Sub

This way, majority of the users can work with the class unchanged. The parent window where the instance is created can access the properties of the Chooser instance to get the :
SelectedDate
SelectedTime
GoActive ( set to true when opening the Chooser in the button action event, false = Chooser window has been closed )
GoButtonSelected ( 0 = Chooser window closed - no button clicked, 1 = Select Clicked, 2 = Cancel Clicked )

Just my 2c. Please ignore if a bad idea.[/quote]

Really anything at this level of the “DateTimeWindow” is open for you to do as much or as little with on a case by case need. My interest isn’t customizing a front end for all to use, but to provide the layer to do this with at your leisure.

[Tim_Hare]

[quote=190708:@Dave OBrien]My point is that if I look at the latest class I downloaded and added to my IDE, the following :

4_Cal-Time Chooser Window … DateTimeWindow … Controls … Finished_Button …
contains the following in the Action Event :

MsgBox “Thank you for using our project!”
[/quote]
You have included too much in your project. I haven’t looked in depth at Mike’s project, but typically in this kind of scenario, you get 2 separate pieces: The classes that you can use in your own project, and a Demonstration window/project that shows how you might use the class/classes. I highly suspect that the msgbox is in the latter.

[Dave_OBrien]

@190718:@Mike Cotrone

Dave this is a button that sits on top of a window. Technically its an object class, but its a class type of button. Terminology may be the difference here.

@190719:@Mike Cotrone

Really anything at this level of the “DateTimeWindow” is open for you to do as much or as little with on a case by case need. My interest isn’t customizing a front end for all to use, but to provide the layer to do this with at your leisure.

Thanks Mike

You are correct. The fact that I have so little experience with these things is undoubtedly making me use incorrect terminology, and this would easily lead to misunderstanding.

I appreciate and now understand about the submit / cancel buttons sitting on the window, and really have very little, if anything, to do with the class itself.

I also agree that your interest and focus should remain on the guts of the class itself.

My only reason for raising the question was so that I could fully understand what impact there would be on my project when you create an update, and I download the 6 folders and drop them into my project, replacing the existing class folders ( with the Submit / Cancel button Action Events included in them ).

I will compile a manual list of the changes I have made and re-enter these after each update.

Thank You again for taking the time to hear my questions and for the depth of your replies. Really appreciated.
Regards

[Tim_Hare]

@190726:@Dave OBrien

replacing the existing class folders ( with the Submit / Cancel button Action Events included in them ).

You shouldn’t import the window or buttons in your project. Only the class/classes that comprise the date picker.

[Dave_OBrien]

@190725:@Tim Hare

You have included too much in your project. I haven’t looked in depth at Mike’s project, but typically in this kind of scenario, you get 2 separate pieces: The classes that you can use in your own project, and a Demonstration window/project that shows how you might use the class/classes. I highly suspect that the msgbox is in the latter.

Hi Tim

From what I have managed to understand ( relevant to what I need ), the project essentially has the following :

1. a calendar / date picker class
2. a clock / time class
3. a window that holds it all together
4. the DateTimeWindow contains the above, the Submit / Cancel buttons, accepts the property set instructions and sets the options for the calendar and clock display and behavior.

@190728:@Tim Hare

You shouldn’t import the window or buttons in your project. Only the class/classes that comprise the date picker.

Point taken – I need to consider that the specific folder ( folder 4 ) that contains the DateTimeWindow does not contain any code that directly affects the class - only code that determines how the DateTimeWindow displays the class.

So bottom line is that once I have the DateTimeWindow doing what I want and the way I want it, there is no reason to ever have to replace it, with the exception of the remote possibility that the author of the class removes or renames one of the properties.
In this case, the app should break at compile time, so this could easily be attended to.

[Dave_OBrien]

@190725:@Tim Hare

You have included too much in your project. I haven’t looked in depth at Mike’s project, but typically in this kind of scenario, you get 2 separate pieces: The classes that you can use in your own project, and a Demonstration window/project that shows how you might use the class/classes. I highly suspect that the msgbox is in the latter.

well, then that is Mike’s fault - sorry Mike

If he hadn’t done such a great job of making the DateTimeWindow look and behave EXACTLY like I need it to, then I wouldn’t be asking the questions.

Thanks again for your input. I have spent the best part of a day on this, and I have learnt SO much from you all.
Regards

[Tim_Hare]

@190730:@Dave OBrien

So bottom line is that once I have the DateTimeWindow doing what I want and the way I want it, there is no reason to ever have to replace it, with the exception of the remote possibility that the author of the class removes or renames one of the properties.

Bingo!

[Thomas_Tempelmann]

Dave, I am not following your entire thread, but if you wonder how to merge changes from two projects, e.g. add changes from one to another, selectively, check out my tool “Arbed”, which is specially made for that task. It lets you compare to projects, also let you optionally see only the classes that appear in both, and then you can select single classes, methods or even lines to merge into the other project.

http://www.tempel.org/Arbed