Test CL.

xfa/fwl/core/ifwl_widget.h

Index: xfa/fwl/core/ifwl_widget.h
diff --git a/xfa/fwl/core/ifwl_widget.h b/xfa/fwl/core/ifwl_widget.h
index e9da806291fcf03edd14c92fb3818f7a910baed4..d64a7b6be9bc4e2c7437dc958f8e0acbfd20da40 100644
--- a/xfa/fwl/core/ifwl_widget.h
+++ b/xfa/fwl/core/ifwl_widget.h
@@ -48,6 +48,7 @@ enum class FWL_Type {
 
 class CFWL_WidgetImp;
 class CFX_Graphics;
+class CXFA_FFWidget;

[Tom Sepez, 2016/05/26 22:34:21]

This is the layering violation.  FWL shouldn't know that XFA exists on top of
it.  FWL is supposed to be an application agnostic layer.

We could try the same trick where IFWL_Widget has some dummy type, but having
done that yesterday, it still feels hokey.

[dsinclair, 2016/05/27 02:57:47]

If that's the case, should we move fwl out of the xfa directory to make the
layering clearer? I was assuming that things inside a top level directory (xfa/,
core/, fpdfsdk/) can see anything in their subtrees.

 class IFWL_App;
 class IFWL_DataProvider;
 class IFWL_Form;
@@ -77,8 +78,8 @@ class IFWL_Widget {
   void SetStates(uint32_t dwStates, FX_BOOL bSet = TRUE);
   uint32_t GetEventKey() const;
   void SetEventKey(uint32_t key);
-  void* GetLayoutItem() const;
-  void SetLayoutItem(void* pItem);
+  CXFA_FFWidget* GetLayoutItem() const;
+  void SetLayoutItem(CXFA_FFWidget* pItem);
   FWL_Error SetPrivateData(void* module_id,
                            void* pData,
                            PD_CALLBACK_FREEDATA callback);