Flickering Edit View since V15

goetti · Apr 05, 2009#12009-04-05T14:58+00:00

Hi there,

Yesterday I've updated to UltraEdit V15 and unfortunately I was very disappointed.

The new UI seems to be based on the toolkit BCG Professional. My company uses this toolkit, too, but you have to do a lot of manual code-fixing & improvements otherwise your APP will not run smooth.

One issue is that due to the massive MDI hacking (for tabbed documents) the BCG toolkit sends a lot of full app redraws. And exactly this issue is present in new UltraEdit. The edit view "flickers" very often. When I activate a window, when I click into the edit, when I start typing, …

It's very disturbing and I hope this issue will be fixed soon.

BTW: Today I've skipped back to UltraEdit V14

rhapdog · Apr 06, 2009#22009-04-06T00:34+00:00

I've not experienced any issues at all with "flicker." Perhaps it's a hardware issue on some machines, I don't know, since I don't experience this issue.

I have noticed a slow-down of performance on several functions, however.

The syntax highlighting issue was also a very large issue for me. I took some time and studied how the new setup handles the syntax highlighting, which, although appears to be more efficient, is much different and not directly compatible. There is a way to convert, but I haven't taken time to write the script to do so as of yet. I have already converted mine manually, so it is not a major issue at this point any longer.

If I get the opportunity soon, I may try to take a day off from work to work on a script that would automate the conversion from 14.x to 15 so that it can be preserved. Of course, I would only be writing a conversion utility for those who use the INI file and not the registry.

The major drawback I see with using this method of syntax coloring within word files is when it comes to "sharing" word files. You are then stuck with the syntax coloring that "someone else" preferred, and you have to go through changes to fix it your way. Not ideal. I'm sure there was a good reason for making this change, though.

lascasas · Apr 06, 2009#32009-04-06T14:55+00:00

I also have this issue with two computers running XP and Vista and reported it during the beta, including sending IDM videos demonstrating the effect. I was very disappointed that UltraEdit released version 15 without resolving the issue and will not be upgrading. The beta was very short from the time there was a public invitation to join to the release, leaving me with the impression they had a release deadline they were going to make regardless of what bugs were found. I could be wrong, of course, since I'm not privy to their internal discussions, but how else to explain Ian's March blog post announcing version 15 in which he says they "will tell the rest of the story next month when v15.00 is out."

Will "the rest of the story" include an explanation of how they allowed this to happen?

danne · Apr 06, 2009#42009-04-06T15:26+00:00

I think it has to do with the 15 years anniversary. However I dunno, and I haven't had any problems with flickering as described.

As for syntax highlighting, I am sure more would be interested in that. There's a discussion about it in the Syntax highlighting forum. I'd do it myself, but I am a bit too pressed for time as I have a conference coming up in two days and I'll be out of the office for a week. I settled for the middle road and half-automated it.

rhapdog · Apr 06, 2009#52009-04-06T15:48+00:00

As I use the same colors/highlighting for all my word files, setting up the first one and a bit of "copy/paste" got me working in short order. I prefer it that way to keep a bit of consistency when I change working languages.

I've considered writing a utility to do the conversion, but since mine is done, and I have other obligations to meet currently, I would receive no benefit. Of course, if 100 people wanted to pay me $1 each guaranteed, I would reconsider.

Writing a blog post with instructions on how to the new word files work in respect to syntax coloring, and how to go about moving it from your old setup to the new, however, is not completely out of the question, if there is any interest in me taking the time to write it all out in detailed instructions.

tom12sg · May 13, 2009#62009-05-13T03:36+00:00

There seems to be a bug within the program. (I'm using v15.00.0.1046). All files in the open file tabs bar seem to refresh again and again for awhile after disable "dockable". After which, if another file tab is selected, the whole file tab disappear ...

Regards,
Tom

Mofi · May 13, 2009#72009-05-13T07:54+00:00

tom12sg,
I'm not able to reproduce what you have written in your last post with UE v15.00.0.1046 on WinXP SP3 using Windows Classic theme. The open file tabs bar work fine with dockable tabs enabled or disabled and with all 3 types of operation. I have selected None for Close Tab Button and don't use tab coloring.

Can you be more detailed and post all the File Tabs settings you currently have enabled in the 3 configuration dialogs for file tabs?

mjcarman · May 13, 2009#82009-05-13T13:35+00:00

tom12sg,
I'm running 15.00.0.1046 as well. If I watch closely I can see the edit area refresh occasionally. It's fairly subtle and usually happens when I'm changing focus so I've never taken much notice of it. I do not see continuous refreshes occurring. I haven't had file tabs disappear but I have lost track of them. Depending on the overflow model you choose not all tabs will be visible at all times. You may need to scroll or check the drop down list.

vhdluser · May 13, 2009#92009-05-13T15:31+00:00

Hi All,

I can confirm the problem of "tab refreshes" on my system.
The "refreshes" seem to go several times over each file, after just about any change of focus (I hope that I'm using this term correctly: clicking new tab, minimizing / maximizing window, closing a dialog, etc...).
It happens with two projects where I have disabled dockable tabs: one with ~60 files, the other with ~11 files.
Also, clicking on a tab does bring up the desired file but the new tab doesn't become active. In case of option "close tab button = on active tab", the "x" stays where it was.

My setup details:

win 2k SP4 + gazzillion security and God knows what KB* patches.
15.00.0.1046
middle button click will close file
sort tabs on file open = ON
dockable tabs = OFF
type = multiline
close tab button = on active tab
tab colors by file spec (I have 10 colour categories)
tabs at the top (but it happens with either top or bottom position).

Results of some experiments:

close tab button = none
The "refresh" problem is still there. There is no "x" to confirm that the tab is or is not "active".
type = single line - drop down
I still see some "refreshing" but more importantly after selecting new file tab, file opens and the whole line with tabs disappears altogether. I have to press twice Alt+Shift+T (my ViewShowHideFileTabs = Show or Hide Open File Tabs) to get it back.
type = single line - scrollable
As above.
sort tabs on file open = OFF
The "refresh" and active tab problem is still there.
With my larger project, these refreshes can take up to 3 seconds of flickering tab display, after simple focus changes. Opening project is delayed by about 8 seconds. Annoying enough to go back and live with the wasted line telling me what tabs are ("Open files").
tab colors by file spec = OFF
The "refresh" and active tab problem is still there.

Incidentally, why isn't the selection of tabs at the top / bottom available in Advanced/Configuration menus. I can only find it in one of the right click context menus.

I hope this helps with reproducing the problem.

Regards,
VU

Mofi · May 13, 2009#102009-05-13T16:09+00:00

I'm quite sure that goetti is right and the IDM developers have to spent time on avoid all the unnecessary redraws. On my old, but very high performance optimized computer I can see only sometimes a refresh of the edit area when switching to another file. But this could be also because of syntax highlighting engine is executed now as a separate thread and therefore MAYBE first the area is shown without syntax highlighting and later again with syntax highlighting. But this is pure speculation.

That the whole open file tabs hide is very strange. I could not reproduce that and I have never seen this behavior. Do you have tried a repair of the whole installation? Maybe something is wrong with the installed files.

vhdluser · May 13, 2009#112009-05-13T20:41+00:00

How do you repair the whole installation?
My 15.00.0.1046 upgrade install is quite fresh (obviously).
Are you suggesting uninstall & re-install?
If some drawing library component were out of date, I would expect that the tab operations with dockable tabs ON would be affected just as well.
I just fired it all off to IDM. Since it looks like reproducing this thing is hit and miss, I don't hold my breath.
Thanks anyways,
VU

tom12sg · May 14, 2009#122009-05-14T00:56+00:00

Hi All,

I tried the installation of v15 Ultraedit on my home PC (Eee PC 1000H), which run WindowXP Home (SP3), classic window setting and the problem that I experience in my office PC didn't occur.
The system in my office is WindowXP Professional version 2002 (SP3), classic window setting. I tried various tag setting configuration and the result is the same whenever I have dockable disable. I have revert the installation back to original version 14.20.1.1001.
I will retry version 15 again when time permit. Thanks.

Regards,
Tom

Mofi · May 14, 2009#132009-05-14T08:43+00:00

vhdluser wrote:How do you repair the whole installation?

By just executing the installer of UltraEdit again from control panel. The MSI installer detects then automatically that this version is already installed and offers you to change components, repair current installation or uninstall the application.

vhdluser · May 14, 2009#142009-05-14T18:55+00:00

Update and the cure:

Thanks Mofi. I tried it - no change.

By now, I'm in contact with IDM about this and they can't reproduce.
They suggested that I get rid of my uedit32.ini file and see - no change. (I restored uedit32.ini but I lost my toolbar customizations -

)

That got me thinking about the long history of my config files.
I created a brand new project and... no problems.
Hm...
I went back to my buggy project and deleted its .pui file and... no problems (except that I've lost record of some of the previously opened files; easily brought back.)
I tried the cure on my second troubled project and it worked there too.

There are lots of differences between the "before" and "after" .pui files and I can't see what's the offending item. I know that I've never edited it by hand.

Well, here you are, tom12sg. Lets see how it works out for you.
Cheers,
VU

arvidj · Oct 10, 2009#152009-10-10T14:25+00:00

I just began using 15.20 at home, which means the laptop is attached to a different LCD monitor than when at work. I immediately encountered the very annoying flicker. An interesting experience is when I had half the window on the big LCD monitor and half the window on the laptop screen. Flicker on one but not on the other. This suggests that the refreshes are taking place - but the ability to see it is monitor dependent - and possibly individual person dependent.

Based on the advice "to remove any .pui files" I was able to rectify the situation immediately. There are some obvious side effects when the .pui files are removed but they are much less of a problem than being unable to use the UltraEdit application at all with the flicker.

Thanks for the research and the suggestion of how to resolve it.