YesNoOk
avatar

Known issues - updated for 0.9.9.x (Read 13038 times)

Started by Nightwish, October 29, 2004, 15:40:14

0 Members and 1 Guest are viewing this.
#1
Known issues - updated for 0.9.9.x |
October 29, 2004, 15:40:14
The following is a list of currently known issues. Please don't report them, because they are known already and may or may not be fixed in the future.

Some of them may be hard to fix and that's why they are still present, others are more trivial to fix, but were ignored for reasons unknown (or just lack of time on my side).

  • Several issues are known when running tabSRMM under Windows 9x/ME. First, the unicode version does not run at all and requires Windows 2000 or later. The ANSI (non - unicode) does run under Win 9x, but with some problems. Crashes under Win 9x are reported, but no solution is available at the moment. Note that tabSRMM requires a RichEdit 3.0 component and that Win 98 ships with a RichEdit 2.0 only (a 3.0 should be available somewhere as an upgrade). I guess, that running tabSRMM with a RichEdit 2.0 can lead to crashes and other serious problems.

  • Multisend is still not perfect. It may cause problems or fail to complete sending all messages. This will improve in the future.
  • When using the IEView plugin, tabSRMM unicode can not display uniocde messages properly. This is a limitation of the IEView plugin.
  • small visual artefacts may appear when using multiple background colors for in- and outgoing messages in BiDi mode (RTL active). This appears to be a non-fixable bug in the RichEdit control happening on some systems running Windows XP.
  • Minor scrolling problems in the message log when enabling/disabling container UI elements like the Menu Bar or Status Bar. The log may not always perfectly scroll to the bottom.
  • SmileyButton not showing - in most cases, this is caused by using the wrong version of smileyadd. TabSRMM only works with the included smileyadd.dll, because it needs extended support for the background colors and provides its own smiley button.
  • No smiley selection window when using IEView. This appears to be a bug in IEView. You can fix it by configuring a smileypack for each protocol in IEView's options dialog. -- fixed in IEView 1.0.1.9

  • Quoting does not work with IEView yet. This is not a bug, but a limitation of the current code. Quoting would need support in the IEView plugin. [added, 11 Mar 2005]

  • crash when hitting enter in the input box in order to insert a new line. Most likely, autoreplacers fault. You may either uninstall autoreplacer or disable its option to capitalize the first letter of each sentence. This should fix the problem.
  • The "automatically popup windows" option gets enabled automatically when Miranda starts. This is a problem with the ZeroNotify plugin. It should not mess with this setting, unfortunately, there is no way to prevent it from doing so.
  • Miranda crashes while resizing the container. Can happen if you have enabled the "snapping windows" support in tabSRMM while running an old version of the snapping windows plugin. Update this plugin or disable snapping windows support in tabSRMM. [added, 12 Mar 2005]
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
Last Edit: March 12, 2005, 14:39:10 by Nightwish
#2
Re: Known issues - updated for 0.9.9.x |
March 29, 2005, 15:59:46
There is a way to prevent the ZeroNotify plugin from making the windows autopopup. I'm sure I described it in the original thread about the problem.
#3
Re: Known issues - updated for 0.9.9.x |
March 29, 2005, 16:31:09
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#4
Re: Known issues - updated for 0.9.9.x |
March 29, 2005, 17:40:09
Yep, that's the one. Worked for me. If you want to keep both plugins that's the way to handle the problem.
#5
Re: Known issues - updated for 0.9.9.x |
July 05, 2005, 13:16:34
latest tabSRMM-Version allways creates the empty Folder
"tabSRMM" in the Miranda-folder is this a Bug?
If not, where do I turn this off ?
#6
Re: Known issues - updated for 0.9.9.x |
July 05, 2005, 13:20:23
latest tabSRMM-Version allways creates the empty Folder
"tabSRMM" in the Miranda-folder is this a Bug?
If not, where do I turn this off ?

It is not a bug and you're not supposed to turn it off.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#7
Re: Known issues - updated for 0.9.9.x |
July 05, 2005, 13:41:20
It is not a bug and you're not supposed to turn it off.
But what is the purpose of creating a empty-folder that i dont want to have ?
(besides it would belong into the plugin folder imhuo :))
#8
Re: Known issues - updated for 0.9.9.x |
July 05, 2005, 18:37:32
It is not a bug and you're not supposed to turn it off.
But what is the purpose of creating a empty-folder that i dont want to have ?

The folder won't stay empty.

Quote
(besides it would belong into the plugin folder imhuo :))

Well, wrong opinion. It *has* to be a subfolder of the profile directory to make sure it is writeable at runtime (think about access permissions on shared computers where every user has his own profile). The programs main folder (and plugins folder) maybe not writeable.


__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#9
Re: Known issues - updated for 0.9.9.x |
July 05, 2005, 18:48:57
The folder won't stay empty.
mh.. runnig since 28.6 and the folder is still empty ???

Well, wrong opinion. It *has* to be a subfolder of the profile directory to make sure it is writeable at runtime (think about access permissions on shared computers where every user has his own profile). The programs main folder (and plugins folder) maybe not writeable.
U dont get me do you ? the folder im talking about is <Path>\miranda\TabSRMM and <Path>\miranda\plugins\TabSRMM
would make more sense :-)
And what do you mean with this The programs main folder maybe not writeable.?
This folder is/must allways writable as Miranda puts the miranda.dat-file there? :-)
#10
Re: Known issues - updated for 0.9.9.x |
July 05, 2005, 19:00:52
The folder won't stay empty.
mh.. runnig since 28.6 and the folder is still empty ???

Well, wrong opinion. It *has* to be a subfolder of the profile directory to make sure it is writeable at runtime (think about access permissions on shared computers where every user has his own profile). The programs main folder (and plugins folder) maybe not writeable.
U dont get me do you ? the folder im talking about is <Path>\miranda\TabSRMM and <Path>\miranda\plugins\TabSRMM
would make more sense :-)

No, it wouldn't make ANY sense as the plugin folder is for the plugins and their global data items.

Quote
And what do you mean with this The programs main folder maybe not writeable.?
This folder is/must allways writable as Miranda puts the miranda.dat-file there? :-)

Well, I guess you don't get me. Your assumption is just wrong. The .dat file does not have to be in the programs main folder. It can, for example, be in your "Documents and settings" subfolder (that is, in your windows profile directory), and on shared computers with multiple accounts, it has to be there. Otherwise, all users would need to share a single miranda profile. Bad idea, hm? tabSRMM creates its subfolder below the folder which holds the .DAT file, NOT below the folder which holds miranda32.exe. This doesn't need to be the same folder.

Please stop this now. The discussion is a waste of time. The folder needs to exist and it needs to exist exactly where it currently does.. And it's really not an issue to complain about. 1000s of programs need their own subfolders to store private data.

BTW: Did you ever complain that the ICQ or MSN protocol create their own folders to store private data (avatars for example) aswell? They also do this under Mirandas main folder, with the same reasons I gave you here.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
Last Edit: July 05, 2005, 19:18:03 by Nightwish
#11
Re: Known issues - updated for 0.9.9.x |
July 05, 2005, 19:40:56
Hey! I wouldnt complain if ANY data would be stored in but as there is not
all Im asking is what is the sense of this folder? ie what data will be stored in there
as I dont find anything in the faq or the docs about that folder... :)
#12
Re: Known issues - updated for 0.9.9.x |
July 05, 2005, 19:44:15
Hey! I wouldnt complain if ANY data would be stored in but as there is not
all Im asking is what is the sense of this folder? ie what data will be stored in there
as I dont find anything in the faq or the docs about that folder... :)

Its used to save your own avatars (when you set them inside tabsrmm). And it may be used to save more private data in the future.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#13
Re: Known issues - updated for 0.9.9.x |
January 23, 2006, 13:06:24
  • small visual artefacts may appear when using multiple background colors for in- and outgoing messages in BiDi mode (RTL active). This appears to be a non-fixable bug in the RichEdit control happening on some systems running Windows XP.

I just wanted to check this first rather than posting a separate bug report: is this what is meant by visual artefacts?  It appears that in certain circumstances a second line of text will be given the wrong colour if the window is just the wrong size (the second picture shows it correctly coloured after i resized it a bit).  Since I don't have RTL active I wasn't sure.  Also, I wonder if it's not something that occurs with smileys only.

Just wondering.
#14
Re: Known issues - updated for 0.9.9.x |
January 23, 2006, 17:27:10
Yes, these are minor richedit glitches when using the \highlight sequence (which tabSRMM needs to use for coloring the background). There isn't much you can do against them other than maybe using a different font, because most of these glitches are caused by incorrect font metrics calculations.

These glitches happen more often when using fixed width, non-truetype or old(er) true type fonts. With modern true type fonts (Tahoma, Verdana etc.), I only see them very rarely.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
Last Edit: January 23, 2006, 17:29:38 by Nightwish