U++ forum: Welcome to the forum

Re: Compiling on Linux... [message #9766 is a reply to message #9747]

Tue, 29 May 2007 23:14

Zardos
Messages: 62
Registered: April 2007

Member

atmks wrote on Tue, 29 May 2007 16:55

Zardos wrote on Mon, 28 May 2007 21:36

Try the attached patch for a possible quickfix.
I'm in the middle of changing the edit markers, so please do not add this patch to the repository.

- Ralf

hi

sorry, but patch not works Sad

same effect

Unfortunately I currently do not have linux installed to reproduce the error.
But I guess the cause of the proble is my "mark edited lines" patch.

So I finally created a patch to remove all markers again from TheIde... Sad

I was fighting a three places:

One place was the problem above. This was the smallest problem and sooner or later this would have been fixed.
As I now understand the pick behavier and my itention was to copy a array which holds the undo-line-marker information, if the file was exchanged in the editor with another file.
...But I was not satisfied with this solution, because all this has caused lots of bugy code.
The problem is: The EditBar holds some line information and when switching between files the line information was fetched from the Ide (after some processing) and set from the Ide. This was no problem - before the line markers appeared - as there was no need to change/remove some line info in all "opened" files and not only in the current one. The result was lots of unnecessary code.
If the Ide would hold all line information for all open files and the EditBar would only reference them... Then there would be no need to Get and Set these line info...
But I didn't want to refracter the code as I still feel new to Ultimate++ and my initial intension was to just add a "small" enhancement.

The second problem is:
Sometimes (when ClearErros is called -> Build) some files loose there edit-markers information. I can only reproduce this bug if I have compiled TheIDE with "optimize" no problems with "debug".
I guess I have not completly understood the numbering (and Renumber) in EditBar... There is probably a problem in GetLineInfo() and/or SetLineInfo()... I'm not completely sure at this...
Anyway the problem is similar to the problem above. The main problem arise from the impossibility to operate on LineInfo objects outside the EditBar. It would be much simpler If I could iterate over all LinInfo objects independently from EditBar and call for example ClearError on a LineInfo object.
But again I have fear of this bigger change....

The third problem are the edit markers itself:
The current code is a ugly hack to allow an undo on edit markers. Together with the aging feature there arise some problems... I don't want to go in to much details, so in short:
I need the ability to synchronize the EditLineInfo-Undo-history with the general editor Undo-history.
But currently there is no straight forward way, because when the virtual functions:

	virtual void PreInsert(int pos, const WString& s);
	virtual void PostInsert(int pos, const WString& s);
	virtual void PreRemove(int pos, int size);
	virtual void PostRemove(int pos, int size);
	virtual void DirtyFrom(int line);
	virtual void SelectionChanged();

...are called the general undo-history is no in its finale state! If the user "is typing" the general undohistory can changed after one of the above functions has been called!
So a undo.GetCount() to get the undo position can lead to the wrong (not what I was expecting) result inside the functions above.
Again to fix this problem I would have to change LineEdit which I do not want to do with my current Ultimate++ knowledge.

So finally I decied to prepare a patch which removes all the markers, again - hopefully without traces...

I feel terrible sorry! I have not expected these kinds of problems for such a "small thing". The "aging" markers together with "undo for markers" triggered the whole problem.
I still would like to have these markers, but I guess I will not find the time to fix all bugs...

Again, sorry Sad

Ralf

Attachment: Remove_Markers.patch
(Size: 22.86KB, Downloaded 458 times)

Report message to a moderator