Netbeans uses standard UndoManager API for implementation of undo functionality. But neither standard javax.swing.undo.UndoManager nor org.openide.awt.UndoRedo.Manager doesn't have any method to mark states as saved and check modified status. Nonetheless if you change the file and press undo, the file is marked as unmodified. How do they do that? I need the same functionality for my (non-text) editors if the Netbeans RCP application.
I figured this out. The CloneableEditSupport adds UndoableEdit when someone saves the file. This edit signals when someone undos from the saved state or redos to the saved state. Also it wraps next edits (up to the first significant one) to intercept redos from the saved state and undos to the saved state.
This trick only works if all UndoableEdits you generate are significant.
Related
I am implementing an editor that works on a distant document. The document is first downloaded, copied in a local cached file, displayed to the user who edits and saves it. On the 'save' action, the document is uploaded back to the server. Classic.
But sometimes, if the distant document has been modified by another user during the download/edit/upload cycle, a conflict is detected and a compare editor is presented to the user : the local version is displayed on the left pane (and editable) and the distant on the right pane (and read-only). The user does the "merge" operation manually (I don't consider automatic merge yet) and when the save action is launched, the comparison result overwrites the localy cached file that is afterwards uploaded onto the server. This is still a classic issue.
The problem is: if the user wants to discard the distant modifications, and thus wants to save the document as is without modifying the left pane, the compare editor refuses to flush the content of the pane in the local file and I can not detect that the user launched the save action to init the upload operation. Why the compare editor refuses to overwrite the local version is quite simple: since no modification has been made, it considers that there is nothing to flush.
I am trying to find a way to make it believe something has changed, but It seems that the TextMergeViewer that handles the comparison is not listening to any model change, and is so far from my code, that I don't know how to reach it (and it seems that I could not set the left pane as dirty anyway).
In my system the user can make changes to JBoss Drools code either through a code editor or a GUI. My problem is if the user makes changes in the code editor and then subsequently in the GUI then the changes from the code editor are lost. Because the GUI tool works by taking a template of the code and plugging in changes made through parameters (FreeMarkerTemplateUtils.processTemplateIntoString).
Does anyone have any suggestions for this problem in general?
One thought was to use Diff Match Patch to somehow merge the changes from GUI with those in the code editor. If this is the way could you please share some code (most of what I found online was just for comparing files not for generating the acutal diff from Strings).
Thanks.
First assumption, the change pattern in code editor would always match with the one GUI uses?
e.g., if the file body pattern is something like
<some text .........>___ReplaceThisString__<some more text ..............>
If it is like that, you could write a method on GUI save, which works something like most of the code repository, like SVN's diff and merge do.
Make a line by line comparison between file saved by code editor (say left) and GUI (say right), you will have 3 conditions,
Only left (changes in a line by code editor content)
Only in right (changes in a line by GUI)
Conflict (a line changed in both code content and GUI)
Ideally, you could merge only left/right without any difficulty, with logic that you take the either change.
For 3rd condition, you must let user decide what to take to maintain correctness of the file functionally, otherwise the file may fail to behave correctly by the next program.
For letting the user decide, you may with to create a compare window showing the user, the difference in two files, and let user simply click on that which one needs to be taken.
Ideally, in all the cases, it is better to show diff and let user confirm that the merge is not breaking the content integrity of the file.
2 things are important here:
A) The merge functionality should be there for code editor as well as in GUI; whenever someone try to save something from code editor. If it is not possible to have this (say you are using a code editor from a 3rd party, e.g. notepad), you should go for 2-step save-promote solution.
In this case, only saving will not change the actual file, rather the file is written in a different location, as a temporary file.
In step-2, 'promote step' - You should have a tool (build one with above strategy) to compare the temp file and original file. Then the user could visually merge the changes.
Same applies for GUI editor.
B) Whenever you do a compare and merge, the original file must be locked for modification, so that another user do not change the file, while somebody is merging.
First off, let me thank the SO community for helping me so many times in the past; you guys are an amazing resource!
At my job I work on a web application that uses PDF templates created in Scribus and the iText Java library to populate the templates with data from our database. Sometimes, a user-supplied field is required and not touched by iText. When the .pdf is downloaded, a field is edited, and a copy is saved with Evince the resulting file will not display the edited text upon reopen. However, upon focus of an edited field it will show the saved text. Unfocus, text disappears. Cut the text, paste back into field; it stays visible - until you save and reopen the document. After save and reopen the original problem manifests. I've found many extremely similar posts regarding this problem, but none of the solutions to which seem to work for me.
Also, the problem is quirky. If I open the Scribus template (the .pdf file untouched by iText) with Evince, then edit fields and save, they will show up properly upon reopen. Once the library touches the template, however, the problem occurs. Similarly, I can reproduce the issue with PDF files I have found while searching for the cause of this problem; like this one:
http://www.quask.com/samples/pdfforms/pcpurchase.pdf
This leads me to believe that the misbehaving files may be corrupted in some way, and that iText may be the cause of my problem, but iText isn't the only avenue in which I can reproduce the issue so I'm not sure what to think. I can't seem to find a working solution among the many I've seen. Is anybody familiar enough with this issue to be able to tell me where I can get to the bottom of this or offer some insight regarding the tools I'm using? Chances are good that if you search for the issue using google I've seen it..
I'm using Ubuntu 12.04 (precise), Evince 3.4.0, iText 2.1.5, and can try to fill you in on any other relevant details upon request. I'm apprehensive to post any code as I'm not sure it is Kosher, and it works fine for constructing forms except with this particular issue; let alone the fact that I can reproduce the problem without the use of our webapp.
This is my first post here, and I am a novice programmer (still in school!) so please do let me know if I have violated any conventions or could improve my future inquiries in any way.
Thanks for any help you can offer!
An inspection of the files supplied by jbowman in the comments to his question --- with special regard to the password field (which is one of the fields entually filled in by evince) --- shows:
Template.pdf
is the original form which was generated by Scribus PDF Library 1.4.1.svn;
contains an AcroForm with 9 fields and the flag NeedAppearances set to true;
has the password field (named passwordField) which contains an empty value and a normal appearance stream painting a rectangle with an empty text.
after_itext.pdf
is the original form edited by iText 2.1.5, unfortunately not in append mode which would have made analysis easier;
contains an Acroform with 8 fields (the member number field has been filled in and flattened) without a NeedAppearances flag;
has the password field (named passwordField:u4woYY1FK9) value and appearances left untouched.
after_itext_edited.pdf
is the form formerly edited by iText now edited by some other software (evince) in append mode;
contains an Acroform with 8 fields without a NeedAppearances flag; the only changes have been made to the fields passwordField:u4woYY1FK9 and memberPrefix:u4woYY1FK9:
has the password field (named passwordField:u4woYY1FK9) with a new associated value asdf but has left its appearances untouched;
has the member prefix field (named memberPrefix:u4woYY1FK9) with a new associated value asdf but has left its appearances untouched.
Thus, the observed behavior that the value by default is not shown, is to be expected:
The final Acroform has no NeedAppearances flag. This flag is defined in the specification ISO 32000-1:2008 as:
A flag specifying whether to construct appearance streams and
appearance dictionaries for all widget annotations in the document
(see 12.7.3.3, “Variable Text”). Default value: false.
Thus, your PDF document in its final form says: No appearances for widgets (e.g. AcroForm field visualizations) need to be generated, take the appearances from the document.
The appearance of the password field from the document is the original one, the rectangle with the empty text.
So you see this empty rectangle.
When you click into the field, the PDF viewer prepares for editing its contents and therefore displays the value as it sees fit.
If editing PDF files with evince is intended to have visible results, evince upon changing the value of the fields must also add updated appearance streams or make sure the AcroForm NeddAppearances flag is set. Therefore, this is where evince failed.
I have accepted mkl's answer as it hits the nail on the head regarding why the fields do not display properly, and contains much more information than I can provide regarding the issue. However, the suggested fix in the answer's comments did not work because the documents are generated (in this particular case) using iText 2.1.5's PdfCopyFields, which does not respect (strips) the original document's NeedAppearances flag, and calling setNeedAppearances(true) for AcroForm did not solve the issue because of this.
Hacking the createAcroForms() method in PdfCopyFieldsImp to include the line
form.put(PdfName.NEEDAPPEARANCES, PdfBoolean.PDFTRUE);
is what ultimately seems to have solved the issue for me. With this addition, evince properly displays changes to fields after saving and reopening the document.
We have 5-10 developers working on Eclipse with Java here in our shop, and we often are debugging classes that don't have debug-friendly toString().
Along comes Detail Formatters to save the day. Hurray! But only my day. If I want to share the joy with my fellow devs, I THINK I have to do some copying and pasting, as do they.
That sucks. We've got N different version control systems that work in Eclipse... it seems like this would be something that folks would Like To Pass Around.
Nothing in the file->export... dialog. Nothing via searching the online help. Nothing.
I managed to track at least some of the settings to /workspace/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.dbug.ui.prefs, but Have Reason To Believe there's more to it than that. Plus, the thought of putting something burried deep in a hidden folder into source control puts my teeth on edge.
Is there a better way to share detail formatters? Ideally this would be something we could just check into our code repo and disseminate that way.
EDIT: I'm using Helios, Service Release 1, build id 20100917-0705.
In addition to the javaLogicalStructures extension point (for adding logical structure to given classes), there's also one called detailPaneFactories. But this is for creating the pane the text (or whatever, thanks to this extension point) the detail formatter renders to. Neither allows extenders to list existing detail formatters (or logical structures for that matter).
The bottom of the detailPaneFactories extension does have Something Interesting To Say:
Supplied Implementation:
The debug platform contributes a detail pane factory providing a default
text source viewer detail pane. The default detail pane displays textual
details of a selected element based on the corresponding debug model
presentation's implementation of computeDetail(IValue value,
IValueDetailListener listener).
computeDetail sounds promising. I'll keep ya posted (unless someone else beats me to it... hurray bounties).
Hmm... org.eclipse.jdt.debug.ui.JavaDebugUtils.getPreferenceStore() sounds promising, but I'd still rather not write a plugin for this myself.
Ah... well. Here's the code org.eclipse.jdt.internal.debug.ui.JavaDetailFormattersManager uses to load them:
/**
* Populate the detail formatters map with data from preferences.
*/
private void populateDetailFormattersMap() {
String[] detailFormattersList= JavaDebugOptionsManager.parseList(JDIDebugUIPlugin.getDefault().getPreferenceStore().getString(IJDIPreferencesConstants.PREF_DETAIL_FORMATTERS_LIST));
fDetailFormattersMap= new HashMap(detailFormattersList.length / 3);
for (int i= 0, length= detailFormattersList.length; i < length;) {
String typeName= detailFormattersList[i++];
String snippet= detailFormattersList[i++].replace('\u0000', ',');
boolean enabled= ! JavaDetailFormattersPreferencePage.DETAIL_FORMATTER_IS_DISABLED.equals(detailFormattersList[i++]);
fDetailFormattersMap.put(typeName, new DetailFormatter(typeName, snippet, enabled));
}
}
So the string in the preference store is just a bunch of CSVs with type-name,snippet,enabled,type-name... replace \u0000 with , in the snippets, and you're good to go.
That handles the export (hell, you could just dump the preference string whole hog).
Import wouldn't be much harder, though it'd be nice to not overwrite existing types, or given the user the option to do so, perhaps even with a diff of the two snippets in question.
OTOH, I'd really rather not rely on the inner workings of a class in *.internal.*.
From the Eclipse 3.8 and 4.2 M5 - New and Noteworthy:
Detail formatters can now be exported as separate preferences.
Previously the only way to share detail formatters was to export all of your workspace settings.
This closes the bug 224815 mentioned by Brian De Alwis in his answer:
"Make Detail formatters exportable" (with that patch)
Although there is nothing explicit in the preferences export wizard, exporting everything will also write the detail formatters. Just search in the output file for /instance/org.eclipse.jdt.debug.ui/org.eclipse.jdt.debug.ui.detail_formatters and share only those lines.
Update: There seems to be a bug in the importer, you have to remove the /instance/ prefix from each line before importing the file.
Alternatively, as they are stored in a properties file in the workspace metadata, you can share that (although you'll probably overwrite other debug settings if you just copy the file):
${workspace}\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.jdt.debug.ui.prefs
Using a "macro" might do the trick here.
You will have to
Install a plugin that lets you
record Macros
Start recording Macro and configure Detail formatters using Eclipse Menus
Save and keep that
macro on some shared directory
Install that plugin and run macro on
PCs used by other developers
One such plugin is : http://sourceforge.net/projects/practicalmacro/reviews/
This issue was filed in the Eclipse Bugzilla as bug 224815. The problem is that the detail formatters were overlooked when configuring the import/export preference transfers. The fix, providing it's accepted, should be in the 3.8/4.2 M6 due out at the end of January.
I like eclipse save actions feature, but I can't get rid of one little annoying thing. I use sorting members and methods on save.
The good thing is, eclipse moves member/method to correct position, alphabetically.
The bad thing is, when I am writing method and save it, eclipse moves method but not current caret position. So basically, I press CTRL+S and end somehwere at completely other place then I was before, so I have to scroll up/down to find new location of my method.
Is there some kind of workaround?
I am using Eclipse 3.6 Helios atm.
It sounds like a bug, try submitting it to eclipse at this site.
As a workaround - but not the best one, you can use Ctrl-O to find the method.
2 more workaround options:
Set a //TODO return here in the line that you want to return to, then you can filter the task view by a specific todo.
Put breakpoint before saving.
Generally I prefer not to use options like this, since when working with other poeple in a large scale project, it can cause a lot of noise. I mean that if you make a change to an existing file, then save it and then the format happen. next step you will commit this file to the repository. when someone or even you try to look at the diff of the change, it will be cluttered with all the formatting and sorting. So I prefer doing it as an independent change.