PDA

View Full Version : classlist.xml



chuckatkinson
14-Sep-2009, 12:00 PM
I'm not sure what has changed recently ? I did a Refresh/Test Class List and get below :


Class can not be found. Make sure the class name (cComPushButton) is correctly named and the file name (Codejock.Controls.v13.0.0.pkg) is correct
Class Palette Error: Could not find class cComTaskPanel in file cComTaskPanel.pkg
Class Palette Error: Could not find class cComSyntaxEdit in file cComSyntaxEdit.pkg
Class Palette Error: Could not find class cComPushButton in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComRadioButton in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComCheckBox in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComGroupBox in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComColorPicker in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComFlatEdit in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComLabel in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComListBox in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComComboBox in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComResizer in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComTabControl in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComTabControlPage in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComPopupControl in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComTreeView in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComListView in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComProgressBar in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComScrollBar in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComUpDown in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComSlider in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComTaskDialog in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComCommonDialog in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComDateTimePicker in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComMonthCalendar in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComWebBrowser in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComTrayIcon in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComHexEdit in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComFormExtender in file Codejock.Controls.v13.0.0.pkg
Class Palette Error: Could not find class cComSkinFramework in file cComSkinFramework.pkg
Class Palette Error: Could not find class cComShortcutBar in file Codejock.ShortcutBar.v13.0.0.pkg
Class Palette Error: Could not find class cComShortcutCaption in file Codejock.ShortcutBar.v13.0.0.pkg
Class Palette Error: Could not find class cComReportControl in file Codejock.ReportControl.v13.0.0.pkg
Class Palette Error: Could not find class cComFieldChooser in file Codejock.ReportControl.v13.0.0.pkg
Class Palette Error: Could not find class cComPropertyGrid in file cComPropertyGrid.pkg
Class Palette Error: Could not find class cComMarkupLabel in file cComMarkupLabel.pkg
Class Palette Error: Could not find class cComDockingPane in file Codejock.DockingPane.v13.0.0.pkg
Class Palette Error: Could not find class cComDockingPaneFrame in file Codejock.DockingPane.v13.0.0.pkg
Class Palette Error: Could not find class cComCommandBars in file Codejock.CommandBars.v13.0.0.pkg
Class Palette Error: Could not find class cComCommandBarsFrame in file Codejock.CommandBars.v13.0.0.pkg
Class Palette Error: Could not find class cComImageManager in file Codejock.CommandBars.v13.0.0.pkg
Class Palette Error: Could not find class cComPrintPreview in file Codejock.CommandBars.v13.0.0.pkg
Class Palette Error: Could not find class cComCalendarControl in file Codejock.Calendar.v13.0.0.pkg
Class Palette Error: Could not find class cComCalendarCaptionBar in file Codejock.Calendar.v13.0.0.pkg
Class Palette Error: Could not find class cComDatePicker in file Codejock.Calendar.v13.0.0.pkg


This was working fine. I went back and did an SVN Update. Still can't find the "Codejock.Controls.v13.0.0.pkg" anywhere ??? And the others above ...

Still everything compiles fine ...

Any ideas?

VDF 14.1
Codejock v13.0.0

chuckatkinson
14-Sep-2009, 12:11 PM
Okay ...

Figured it out. Razzlefrazzel.... freeking TortoiseSVN corrupted my classlist.xml file when it updated with changes from the repository. Putting >>>>>>>> and revision stuff in the file.

Used SVN plugin in Eclipse to fix the problems. That's it for Tortoise.... it's off my computer from now on ...

Garret Mott
14-Sep-2009, 12:29 PM
Okay ...

Figured it out. Razzlefrazzel.... freeking TortoiseSVN corrupted my classlist.xml file when it updated with changes from the repository. Putting >>>>>>>> and revision stuff in the file.

Used SVN plugin in Eclipse to fix the problems. That's it for Tortoise.... it's off my computer from now on ...

Hi Chuck -

I exempt all the xml files (especially classlist) from Tortoise & stuff works fine. Working on a project now where I don't have it & I miss it!

chuckatkinson
14-Sep-2009, 03:39 PM
So then how would you get the classlist.xml for the VDF Sig classes from SVN if it's exempted?

Garret Mott
15-Sep-2009, 06:51 AM
So then how would you get the classlist.xml for the VDF Sig classes from SVN if it's exempted?

Well - I think I'd first get out my soldering gun....

Seriously though - I was speaking from the point of view of developers sharing files. I think the "problem" is more with how VDF seems to rewrite classlist.xml so regularly.

In your situation, I'd rename it before synching with the server & then compare the 2 on my own.

Stephen W. Meeley
15-Sep-2009, 07:28 AM
Garret,



I think the "problem" is more with how VDF seems to rewrite classlist.xml so regularly.


Huh?

Garret Mott
15-Sep-2009, 07:45 AM
Garret,



Huh?

Hi Stephen -

Long winded reply....;) My statement was based on 14 & 14.1 experience where we had to exclude classlist.xml from version control because we regularly had conflicts in it & ended up with a file like the one Chuck describes - full of >>>>>...mine & >>>> .1028, etc.

The only way I know for these to get in there is for my version to be newer than my last update & then update again. Since this seemed to happen several times a week, we simply excluded it from SVN & life got much simpler.

Maybe we should have pursued the why further, but (as usual) we were in "crank out the app" mode & didn't want to spend the time.

Here's a thread that goes into it a bit: http://support.dataaccess.com/forums/showthread.php?p=185203#poststop

And another: http://support.dataaccess.com/forums/showthread.php?t=38103&highlight=classlist.xml

In the latter, Vincent explains when it gets written, but our experience seems to be that it happens more often than that....

Stephen W. Meeley
15-Sep-2009, 08:53 AM
Garret,

I fully understand that the formatting of XML files in prior revisions was messing up source control, but I believe we fixed that. Are there still any source control issues caused specifically by the formatting of the XML files?

Once the file can be properly handled in source control, saying that the frequency of it being updated is the cause of problems was what triggered my Huh?

I don't believe you would hold any other component of a project, say a piece of source for instance, to a "don't update it too often - we wouldn't want to have to merge the changes in source control" standard. IMHO, environment changes (that need to be tracked) are no different than source changes. They happen when you change something and they need to get merged if two or more developers make changes in that area.

Now if files were changing even when the developer made no changes at all, that would certainly be an issue we'd want to look at (just like formatting was).

Garret Mott
15-Sep-2009, 09:05 AM
Garret,

I fully understand that the formatting of XML files in prior revisions was messing up source control, but I believe we fixed that. Are there still any source control issues caused specifically by the formatting of the XML files?


Dunno - since it's been excluded for so long....



Once the file can be properly handled in source control, saying that the frequency of it being updated is the cause of problems was what triggered my Huh?
I may have been wrong about the why - but I leaped to that conclusion based on seeing the date change often. Maybe it was a 14 issue that got fixed in 14.1



I don't believe you would hold any other component of a project, say a piece of source for instance, to a "don't update it too often - we wouldn't want to have to merge the changes in source control" standard. IMHO, environment changes (that need to be tracked) are no different than source changes. They happen when you change something and they need to get merged if two or more developers make changes in that area.
You are correct - but we deemed the class changes to be something that happened rarely & therefore could be dealt with manually.



Now if files were changing even when the developer made no changes at all, that would certainly be an issue we'd want to look at (just like formatting was).I just checked the date of classlist.xml in that project & it is indeed months old - so I guess it was changed/fixed in 14.1 - so all this was a waste of your time. Sorry!

Ian Smith
16-Sep-2009, 10:57 AM
I have experienced the same issue with a “standard” source file once or twice. The >>>> implies that the file is the result of a version compare. I have an Araxis Merge license and have reconfigured SVN to use that for comparing and merging and I don’t think I have had the problem since.

I may be wrong but I think SVN inserts the >>>> when it can not workout how to merge the different versions. This results in a file with the code from two different versions (identified by the >>>>) which you are supposed to then sort out.

The classlist.xml files for all the SigCJ workspaces are in SVN and I have not had any problems.

Garret… go on be a rebel, put classlist.xml back in SVN:D

Garret Mott
16-Sep-2009, 12:50 PM
I have experienced the same issue with a “standard” source file once or twice. The >>>> implies that the file is the result of a version compare. I have an Araxis Merge license and have reconfigured SVN to use that for comparing and merging and I don’t think I have had the problem since.

I may be wrong but I think SVN inserts the >>>> when it can not workout how to merge the different versions. This results in a file with the code from two different versions (identified by the >>>>) which you are supposed to then sort out.

The classlist.xml files for all the SigCJ workspaces are in SVN and I have not had any problems.

Garret… go on be a rebel, put classlist.xml back in SVN:D

Oh yeah - I've definitely seen that in source. I must admit that I've never spent the time to figure out how Tortoise does file compares/resolution - as it was not intuitive to my little brain. I just grab my original & the "new" & use WinMerge.

I could never even think of being a rebel! I've always been a strictly law abiding, go with the majority kinda guy... Oh wait, I use VDF don't i? :eek:

Yes officer, I was in a 4 wheel drift - but it was a controlled 4 wheel drift!

Ian Smith
16-Sep-2009, 01:17 PM
I've never spent the time to figure out how Tortoise does file compares/resolution - as it was not intuitive to my little brain. I just grab my original & the "new" & use WinMerge.

Yep - that's why I configured Tortoise to use Araxis Merge