* commit 'ooo/DEV300_m101': (185 commits)
chart52: cleanup unused legend entry stuff in preparation of issue #i82802#
masterfix: #i10000# add missing dependency in offapi
sb138: #i115619# fix for MinGW
sb138: #i115619#, #i116038# use osl_setThreadName in binaryurp
sb138: #i115619# osl_setThreadName
gridsort: i116682: update UnoControlDialog to reflect XDialog
gridsort: minor changes to the new API: - renamed XMutableGridDataModel::setRowHeading to updateRowHeading for consistency reasons - renamed XSortableGridDataModel to XSortableGridData - actually, this is not a full-fledged model in itself.
gridsort: grid control related unit tests (first set, more to come)
sb138: #i116038# fresh implementation of binary URP bridge
chart52: #28670# make the legend within charts resizeable - part 2
gridsort: re-did the column resizing - introduced XGridColumn.Flexibility, determining to which degree the column is resized during auto-column-resizing - removed XGridColumn.PreferredWidth - there really is no need for this anymore now - documented the relationship between XGridColumn.Flexibility and XGridColumn.Resizeable - re-implemented TableControl_Impl::impl_ni_updateColumnWidths, with (hopefully) less magic
sb139: #i116530# improve Java URP bridge error notification by utilizing the java.lang.Throwable cause facility
gridsort: document the relationship between soorting the data and notifying XGridDataListeners
gridsort: introduce XGridColumn::DataModelIndex. this allows for column removal/insertion at the GridColumnModel, without the need to touch the GridDataModel
locales34: #i112431# adapt documentation to reality
gridsort: introduce XSortableGridDataModel::removeColumnSort
gridsort: #163172# added UNO API support for sorting grid data. Implementation still unfinished. Things missing in the SortableGridData implementation - add as listener to the delegator, so we're notified of changes - translate and multiplex those changes - do own notifications (XGridDataListener.dataChanged) when the sort order changed - (possibly) update the sort order when the data in the current sort-column changed
gridsort: made the row title a row heading, being an Any instead of a string
gridsort: XMutableGridData: renamed updateRow to updateRowData for consistency; introduced updateRowToolTip as shortcut for multiple updateCellToolTip calls
gridsort: updateCell->updateCellData, setCellToolTip->updateCellToolTip; in both methods, have (Col,Row) params instead of (Row,Col), for consistency reasons
...
Conflicts:
bridges/inc/bridges/remote/bridgeimpl.hxx
bridges/inc/bridges/remote/connection.h
bridges/inc/bridges/remote/context.h
bridges/inc/bridges/remote/helper.hxx
bridges/inc/bridges/remote/mapping.hxx
bridges/inc/bridges/remote/proxy.hxx
bridges/inc/bridges/remote/remote.h
bridges/inc/bridges/remote/remote.hxx
bridges/inc/bridges/remote/stub.hxx
bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx
bridges/source/remote/context/context.cxx
bridges/source/remote/static/helper.cxx
bridges/source/remote/static/mapping.cxx
bridges/source/remote/static/proxy.cxx
bridges/source/remote/static/remote.cxx
bridges/source/remote/static/remote_types.cxx
bridges/source/remote/static/remote_types.hxx
bridges/source/remote/static/stub.cxx
bridges/source/remote/urp/urp_bridgeimpl.cxx
bridges/source/remote/urp/urp_bridgeimpl.hxx
bridges/source/remote/urp/urp_cache.h
bridges/source/remote/urp/urp_cache.hxx
bridges/source/remote/urp/urp_dispatch.cxx
bridges/source/remote/urp/urp_dispatch.hxx
bridges/source/remote/urp/urp_environment.cxx
bridges/source/remote/urp/urp_job.cxx
bridges/source/remote/urp/urp_job.hxx
bridges/source/remote/urp/urp_log.cxx
bridges/source/remote/urp/urp_log.hxx
bridges/source/remote/urp/urp_marshal.cxx
bridges/source/remote/urp/urp_marshal.hxx
bridges/source/remote/urp/urp_marshal_decl.hxx
bridges/source/remote/urp/urp_property.hxx
bridges/source/remote/urp/urp_propertyobject.cxx
bridges/source/remote/urp/urp_propertyobject.hxx
bridges/source/remote/urp/urp_reader.cxx
bridges/source/remote/urp/urp_reader.hxx
bridges/source/remote/urp/urp_replycontainer.hxx
bridges/source/remote/urp/urp_threadid.cxx
bridges/source/remote/urp/urp_threadid.hxx
bridges/source/remote/urp/urp_unmarshal.cxx
bridges/source/remote/urp/urp_unmarshal.hxx
bridges/source/remote/urp/urp_writer.cxx
bridges/source/remote/urp/urp_writer.hxx
cppu/source/threadpool/threadpool.cxx
cppu/util/target.pmk
cppuhelper/qa/propertysetmixin/comp_propertysetmixin.cxx
cppuhelper/source/interfacecontainer.cxx
cpputools/source/regcomplazy/regcomplazy.cxx
jurt/prj/d.lst
jvmfwk/source/elements.cxx
offapi/com/sun/star/awt/grid/GridDataEvent.idl
offapi/com/sun/star/awt/grid/XGridColumn.idl
offapi/com/sun/star/awt/tab/makefile.mk
offapi/com/sun/star/chart2/ExplicitIncrementData.idl
offapi/com/sun/star/chart2/XPlotter.idl
offapi/com/sun/star/chart2/XUndoHelper.idl
offapi/com/sun/star/document/MediaDescriptor.idl
offapi/com/sun/star/document/makefile.mk
offapi/com/sun/star/linguistic2/XLanguageGuessing.idl
offapi/com/sun/star/script/ModuleInfo.idl
offapi/com/sun/star/script/ModuleType.idl
offapi/com/sun/star/text/TextMarkupType.idl
offapi/com/sun/star/util/XTextSearch.idl
offapi/com/sun/star/xml/sax/XFastAttributeList.idl
pyuno/source/loader/makefile.mk
remotebridges/source/bridge/bridge_connection.cxx
remotebridges/source/bridge/bridge_connection.hxx
remotebridges/source/bridge/bridge_provider.cxx
remotebridges/source/bridge/remote_bridge.cxx
remotebridges/source/bridge/remote_bridge.hxx
remotebridges/source/dynamicloader/dynamicloader.cxx
remotebridges/source/factory/bridgefactory.cxx
remotebridges/source/factory/bridgeimpl.cxx
remotebridges/source/factory/bridgeimpl.hxx
remotebridges/source/factory/makefile.mk
sal/cppunittester/cppunittester.cxx
sal/inc/osl/diagnose.h
sal/osl/os2/system.h
sal/osl/unx/diagnose.c
sal/osl/unx/file_misc.cxx
sal/osl/unx/process_impl.cxx
sal/osl/w32/diagnose.c
sal/osl/w32/process.cxx
sal/prj/build.lst
sal/qa/rtl/math/makefile.mk
sal/qa/rtl/math/rtl_math.cxx
sal/qa/rtl/math/rtl_old_testint64.cxx
sal/qa/rtl/math/test_rtl_math.cxx
sal/systools/win32/kill/kill.cxx
sal/textenc/tencinfo.c
sal/util/sal.map
stoc/source/inspect/introspection.cxx
stoc/source/security/file_policy.cxx
stoc/source/simpleregistry/simpleregistry.cxx
Now I have some understanding what it is the code here should do, and
have found 3rd-party documentation (in source code form even) for the
exception-related data structures.
It still crashes, but I hope that is just because of thinkos that need
to be fixed by debugging, or reading the code. There are some horrible
code with quite complex casts in places, I need to introduce some
macros or inline functions instead to make the casting from RVAs to
real pointers and back cleaner. Also maybe just use DWORD instead of
sal_uInt32 for terseness, and use a specific typedef name for DWORDs
that actually are RVAs for clarity?
I had implemented a couple of basic things quite wrong, partly because
of easily misunderstood Microsoft documentation. A couple of things I
just had forgot to do properly.
Attempt to make the source code more consistent in spacing and
variable naming. Clean away meaningless vertical space wasting
non-verbal comments.
The bridgetest over in testtools now runs through quite a lot of its
paces successfully. But exception handling and RTTI, the stuff in
except.cxx, is still not really done at all. And even if I comment out
those checks in bridgetest so that no exceptios are thrown, I then get
a crash later.
It simplifies function table and unwinding info management, as those
are now static for the privateSnippetExecutor() function in
call.asm. Even if it is slightly ugly to have to poke in more
instructions in codeSnippet().
Out privateSnippetExecutor() is much simpler than the x64 Linux one,
thanks to the simpler calling convention.
Now the call through the trampoline into cpp_vtable_call() seems to
work, but I get a crash later. Glitches in parameter passing, no
doubt. Debugging needed in cpp_vtable_call() and cpp2uno_call().
The basic implementation is probably sane. But I wonder if I after all
should have done like in the x86-64 Linux implementation, with the
dynamically generated trampoline just jumping into fixed code shared
between all trampolines. Probably should redo it like that, yes.
Will it then cause a problem for OS unwinding if the caller of the
trampoline calls a short dynamically generated code snippet, which
then jumps into the fixed part, and only the fixed part has a
(assembler-generated) function table and unwind info? Probably not.
It is quite impossible that such a short dynamically generated snippet
with just a couple of instructions would cause an exception, and when
we have jumped into the fixed part, where the call to
cpp_vtable_call() is done, it doesn't matter any more that the caller
in fact didn't call what the function table claims is the entry
point. Or does it?
Doing it that way would mean no RtlAddFunctionTable() and
RtlDeleteFunctionTable() would be needed, and especially doing the
latter correctly is a bit hairy.
I think I might actually be able to manage without any assembly coding
here, thanks to the clean design of the x64 Windows calling
convention, and tricking the compiler (in a fully documented and
stable way) by using varargs. uno2cpp.cxx might even be getting close
to working now, but cpp2uno.cxx and except.cxx parts are just forced
to compile by using dummy code.
