how to export PRJ file without BreakPoints?
Is it possible to export PRJ file without section BreakPoints and Target attribute? /diffexport does't help.
They just make noise when pushing into GIT
Comments
You could create a macro that conditionally compiles the break points into your code based on the existence of a global variable.
That's too complicated for my needs. I export with my own tool so it would be easier to change the tool to clear breakpoints before the export
Breaks maybe? AFAIK break points are unaffected by compilation.
sorry, not sure what you mean. please elaborate
There are:
I don't like idea to set breakpoints in source code. At least because once set, you have to remember to remove it. This way is the only way for hardcore OS-level debugging but for application programming today I would prefer adequate debugger
Here's a snippet from my Studio Extension (a subclass of one of the more standard extensions) that you might use and adapt in yours. It deals with a few other things that /diffexport misses - the timestamp, and the order of project items (which will normally have newly-added items at the bottom, out of alphabetical order). Unfortunately, I haven't found a way to handle breakpoints - probably the easiest way to get rid of those would be applying an XSLT to the file after it's been exported, which is pretty bad.
Method OnAfterSave(InternalName As %String, Object As %RegisteredObject) As %Status
{
Set tFileName = ..ExternalName(InternalName)
If tFileName = "" {
Quit $$$OK
}
Set tName = $Piece(InternalName,".",1,*-1)
Set tExt = $ZConvert($Piece(InternalName,".",*),"U")
// Special handling for projects to ensure that newly-added items don't show up at the bottom of the XML export.
// This tends to cause meaningless diffs (at best) and conflicts (at worst)
If (tExt = "PRJ") {
Set tProject = ##class(%Studio.Project).%OpenId(tName,,.tSC)
If $IsObject(tProject) {
// Save the project for real (we'll be in %OnAfterSave for the project when this happens,
// but %Studio.SourceControl.Interface protects against <FRAMESTACK> by moving %SourceControl
// to tmp, so this should be perfectly fine).
// If the project is not saved, the items will be in the wrong order.
If tProject.%Save() {
// Reload the project. We need to save first to be sure all ProjectItem changes are commited.
// This will load them up freshly, in the normal order.
Do tProject.%Reload()
}
// Clear a few properties, since /diffexport won't be respected.
// This won't actually be saved, but these things shouldn't be in the export to disk.
Set tProject.LastModified = ""
Set tProject.Target = ""
Set tProject.TargetType = ""
}
}
Quit ##super(.InternalName,.Object)
}Looks interesting, thanks for sharing.
What is your problem with breakpoints? As I recall, they are just a collection property of Project object, so you shouldn't have any problems at least to clear them.
BTW: why it is important for you to have project items sorted alphabetically?
The problem with using the strategy from that code snippet on breakpoints is that they're separate persistent objects - the approach in the code snippet is to make a temporary change to the object that will be exported, but this doesn't seem to work (after a few attempts with different approaches) for breakpoints without breaking things in Studio.
Having project items sorted alphabetically is helpful to avoid conflicts in source control with multiple people working on the same project at the same time.
Example:
User A adds a file. User B adds a file. User A commits their change. User B goes to commit their change and can't because a conflict is detected due to User A's change to the same line of code (because both added new project items at the end of the list).