#479 Dragging a control bar does not draw a frame in some programs.

[Ognyan Chernokozhev]

In some of the example projects, which contain a control bar (RichEditor, FolderSize), when that control bar is being dragged to a non-edge location, the drag frame is not painted.

In other pojects, for example OWLMaker, the drag frame is painted correctly.

[Ognyan Chernokozhev]

Note: in 6.30 this appears to work correctly. It is broken in both 6.44 and trunk.

[Ognyan Chernokozhev]

The drag frame is drawn with a hatch brush, which is created as a static singleton object.

struct TDitherBrush
#if defined(BI_MULTI_THREAD_RTL)
                : public TLocalObject
#endif
{
  TDitherBrush():Brush(THatch8x8Brush::Hatch11F1)
    {
    }
  ~TDitherBrush()
    {
    }

  THatch8x8Brush Brush;

#if defined(BI_MULTI_THREAD_RTL)
//  TMRSWSection  Lock;
#endif
};

//
// Static instance of the colors
//
static TDitherBrush& GetDitherBrush()
{
#if defined(BI_MULTI_THREAD_RTL)
  static TTlsContainer<TDitherBrush> ditherBrush;
  return ditherBrush.Get();
#else
  static TDitherBrush ditherBrush;
  return ditherBrush;
#endif
};

I found out that if I comment out the static initializer in these lines

namespace
{
  //
  // Ensure singleton initialization at start-up (single-threaded, safe).
  //
  TDitherBrush& InitDitherBrush = GetDitherBrush();
}

then the frame is drawn correctly in the RichEditor example.

On a side note, there is a LOCKBRUSH macro which is always empty - it should be removed from code.

[Vidar Hasfjord]

Hi Jogy, good catch.

It seems the attempt to create the TDitherBrush at startup fails for some reason. Do you know why?

Anyway, this is one of my regressions, as part of the multi-threading review. The statically initialised InitDitherBrush was added to prevent race conditions on the initialisation of ditherBrush, the static variable within GetDitherBrush. However, OWLNext isn't thread-safe anyway, so it was somewhat pointless. Also, with C++11 compliant compilers, the initialisation of static variables at function scope is now guaranteed to be thread-safe, so the workaround is not needed on the trunk.

[Ognyan Chernokozhev]

Fixed in [r5283] in trunk, in [r5284] in 6.44 and in [r5285] in 7.0.