Forum

I download 2.43.
and found that these functions are no use at all.

Yes, in the CExtGridCell class these virtual methods are empty and there are no variables which store the colors. In other words CExtGridCell class does not hold text/background colors. It’s a kind of lightweight class used by other derived classes. We added the CExtGCC template that allows a CExtGridCell-derived class to hold these values. CExtGCC template is designed to decorate any CExtGridCell-derived class. It overrides these virtual methods and allows you to specify text and background colors.

We also added the CExtGridCellEx class which implements a cell which is usually used as a base class for other cell objects with custom text and background colors and a custom hover cursor.

Is it the default behaviour for the CExtDateTimeWnd when showing both a date and time that when you select a new date the time reverts to 12:00:00 am and if so is there a way to stop it doing that?  Also if the CExtDateTimeWnd is showing both a date and time say 9/09/2005 2:00:00 pm when you change the 2 to a 3;  pm changes to am can this be stopped also?

Regards,

       Eddie

Hello

I am afraid this was asked and answered a thousand times but I couldn’t find it in the forums. How can I prevent a toolbar from floating?

Thanks

Thomas

 

While the answer from Tech Support was correct it did not fully apply to my situation. If you have more than one control bar tabbed into one "container control bar" and you want to restrict certain things on that then you will have to derive a class from CExtDynamicTabbedControlBar and apply certain restrictions there. However, if you want to set the initial size of this bar you will have to do it in one of the tabbed control bars.

Attention: You will have to include a file from the source directory (which is very ugly in my opinion): ..\Src\ExtControlBarTabbedFeatures.h

General comment: If you try to rely on the documentation you will end up asking Tech Support questions all the time. I have used many features (classes, methods) so far that were not in the Reference Manual. I learned a lot by studying the sources and stepping through their code with the debugger.

 

 

This does not work well when dragging/dropping bar previously docked in tabbed container. Bar is removed from tab container on drag start but is not created on drop (if dropping in place where it should become floating). What should be changed to cover this case as well?

It’s a little bit late to answer that one but I do it for future generations ;-)

You can prevent dragging by overriding _DraggingStart in your Control Bar and doing nothing in it.

The solution we advised in the previous message relats to the toolbar/menu bar only. We have already resolved the "prevent floating", "prevent closing", "prevent resizing" issues in Prof-UIS 2.50. Please contact us by e-mail so we can provide you with instructions on how to download this update.

Hello

I have a CExtControlBar which can be auto hidden. Everything seems to work fine but one thing: When the bar is hidden and is reopened again it seems to go to the background. It can be seen flickering and will then be hidden. When one clicks to where the bar should be the bar comes up again. For test reasons I put a listbox into the bar. When the bar with the listbox reappears the listbox is transparent (with a focus rectangle where the first item should be). What goes wrong?

BTW, when pinned everything is ok.

 

Thanks

 

Thomas

 

Hello Thomas

I have the same problem, also in a MDI Application.
But adding the WS_CLIPSIBLING style does not make any difference - the reopen bars are still in the background.

How did you solve this problem?

Thank you
  Marcus

 

Marcus

I only saw your message now (Dec 6). If you still need help with that then contact me under thomas.maurer-replacethiswholestuffincludinghyphenswithyouknowwhichsign-ierax.ch

Your name says you could be a German speaker and so am I (es geht also auch auf Deutsch)

Thomas

Dear Marcus,

You should not encounter this problem in the MDI application because the MDI client window already clips siblings. Are you sure your application is MDI?

We may guess you have an SDI application and the main view window does not have the WS_CLIPSIBLINGS style. Please take a look at the CChildView::PreCreateWindow() method and check whether it adds the WS_CLIPSIBLINGS style. Your method may look like:

BOOL CSDIDOCVIEWView::PreCreateWindow( CREATESTRUCT & cs )
{
    if( ! CView::PreCreateWindow(cs) )
        return FALSE;
    cs.style |= WS_CLIPSIBLINGS;
    return TRUE;
}

This problem does not occur in MDI applications because the MDI client container window has WS_CLIPSIBLINGS style turned on by default.

Thank you. That helped a lot. I am using MDI but the bar is in the mdi child not in the mdi frame but I was able to figure that out myself :-).

 

Hi,

 I have a little question about access to CExtGridWnd derived class in a thread.

My application is a MDI apps, the view is a derived class af CView. Inside a CMyView, I have a CMyGrid (derived from CExtGridWnd).

I’m trying to load data into CMyGrid from a thread in the following manner:

declaration of thread function

static unsigned __stdcall my_function(LPVOID *lpVoid);

 

unsigned __stdcall CMyView::my_function(LPVOID *lpVoid)

{

 

}

 

The MFC library has thread state data for each running thread. These data contain maps of handles to MFC objects such as a map from HWND handles to CWnd pointers. This means you can use any CWnd-derived class only in the thread where it was created. You cannot use this class in another thread because you will face assertion problems. The assertions are triggered because the CWnd pointer is controlled by the internal MFC map of other thread.

Here is what can be done. Define your WM_USER+??? messages and send them to the grid control from another thread. These messages should have pointers to non-MFC based data structures in message parameters. This is a valid way of interaction between a CWnd-based window and other thread. This approach is used in the CLogCtrl::WriteText() method of the MthOutput sample application. The CLogCtrl class implements a log output window which is based on the rich edit control. The CLogCtrl::WriteText() method invokes rich editor’s APIs if it is invoked from the same thread in which the log control was created. This method sends the WM_USR_WRITE_LOG_TEXT message that is defined as (WM_USER + 0x1234) to the rich editor’s thread if the method is invoked from another thread. The WM_USR_WRITE_LOG_TEXT message uses the CLogCtrl::_MthMessageDataFor_WM_USR_WRITE_LOG_TEXT data structure to pass all the needed information and invoke the CLogCtrl::WriteText() method in the rich editor’s native thread.

Hi,

I use a subwindow that setup its own profile. In that window, I have some docked toolbars that work fines. But, if I try to move one of them to change its state to floating mode, I get an assertion on line 451 of the ExtToolControlBar.cpp. (v2.40) The assertion validate a command item pointer. I just don’t understand why it cannot find it if my toolbar becomes in floating mode. The problem happend on the OnPaint method of a CExtBarButton. All my toolbars implement a combo box or a slider. So, any idea?? Do I forgot the setup something in the command manager?

Tanks

Each command profile in the command manager has one or more HWND handles associated with this profile. Typically it is an HWND handle to the main frame window. The command profile searching algorithm for any window is based on iterating over HWNDs both to this window and to all its parent windows until some handle is not found in some command profile in the command manager. The floating mini frame window with toolbars is a child of the main frame window in a simple frame-based MFÑ application. So, each toolbar window can walk through its parents and stop at the main frame window whose HWND is used in the command manager’s profile. In your case, the frame window is not a top level pop-up window. The floating mini frame window with toolbars has the parent window which contains your frame window somewhere inside. So, any toolbar in the floating state is unable to use the command manager. The solution to this problem is very simple: add HWND of the top level frame window to the same command profile which is initialized for your standalone frame window. Here is how your command profile initialization in the CYourFrame::OnCreate() method may look like:

int CYourFrame::OnCreate( LPCREATESTRUCT lpCreateStruct )
{
    if( CBaseOfYourFrame::OnCreate( lpCreateStruct ) == -1)
        return -1;
CWinApp * pApp = ::AfxGetApp();
    ASSERT( pApp != NULL );
    ASSERT( pApp->m_pszRegistryKey != NULL );
    ASSERT( pApp->m_pszRegistryKey[0] != _T(’\0’) );
    ASSERT( pApp->m_pszProfileName != NULL );
    ASSERT( pApp->m_pszProfileName[0] != _T(’\0’) );
    ASSERT( pApp->m_pszProfileName != NULL );
    g_CmdManager->ProfileSetup(
        pApp->m_pszProfileName,
        GetSafeHwnd()
        );
    g_CmdManager->ProfileSetup( // !!! IMPORTANT !!!
        pApp->m_pszProfileName,
        GetTopLevelParent()->GetSafeHwnd()
        );
    . . .

Of course, you should remove both HWND handles from the command profile in the CYourFrame::DestroyWindow() method. The CExtCmdManager::ProfileWndRemove() allows you to deallocate the command profile and destroy all the icons and command descriptions when removing the last HWND handle from this profile. Invoke this method for both HWND handles and specify true in the bRemoveProfileIfLastHWND parameter.

The solution described above is essential when you code an ActiveX component which looks like an independent frame window with dockable bars inside. The very same approach is used in the Prof-UIS Frame Features ActiveX control.

Tanks. It works!

Unfortunately I don’t know the solution for the problem, but almost the same happens for me, too. But when I remove the customization from my project, it works again. So might be something about that. Even though, I eagerly wait for the answer, too. Chris

Hi!

I’ve tried to do the steps described below to the LanguageSwitcher project.

Make the following changes below in the profuislib project:
1. Open the Prof-UIS workspace and make the profuislib project active;
2. Open the Prof-UIS.h file and comment the following lines:

// #if (!defined _AFXDLL || defined __STATPROFUIS_WITH_DLLMFC__) 
//     #define __EXT_MFC_NO_CUSTOMIZE 
// #endif // (defined _AFXDLL || !defined __STATPROFUIS_WITH_DLLMFC__)




3. Add the following files to the project:
    ./Include/ExtCustomize.h
    ./Include/ExtIconEditDlg.h
    ./Src/ExtCustomize.cpp
    ./Src/ExtIconEditDlg.cpp
4. Select the required configuration and build the project.

Make some changes in your application:
1. Copy the ./profuisdll/profuisdll.rc file to the project’s directory.
2. Open profuisdll.rc in the text editor, find the VS_VERSION_INFO section and remove this entire section.
3. Copy the ./profuisdll/idd_ext_color_dlg.ico file to your project’s directory.
4. Copy the contents of the ./profuisdll/res directory to your ./res directory.
5. Add the #include "profuisdll.rc" line just after the comment "Add additional manually edited resources here..." in your application’s ./res/*.rc2 file. If you do not do this, the Prof-UIS assert at startup because it is trying to access resources that are not available.
6. Copy all constant definitions from the ./profuisdll/resource.h file to your resource.hresources

I’ve also removed any resources that haven’t to do with English from profuisdll.rc as you recommended. And one more thing to add: in Prof-UIS.h there is one more #define by those lines, like this:

// #if (!defined _AFXDLL || defined __STATPROFUIS_WITH_DLLMFC__) 
//     #define __EXT_MFC_NO_CUSTOMIZE 
//     #define __EXT_MFC_NO_DYNAMIC_BAR_SITE 
// #endif // (defined _AFXDLL || !defined __STATPROFUIS_WITH_DLLMFC__)

I compile the project with the same project-properties as I did with profuislib project, and it compiles without any warning. Still, when I try to run the application I get an unhandled exception. Checking the stack in debug I can see that the problem starts in CMainFrame::OnCreate() at CExtCustomizeSite::MenuInfoLoadAccelTable().

Could you give me any explanation for that?

Thank you: Chris

As we mentioned before, we stick to the idea of the statically linked application as a light-weight application that do not use resources. If you need resources and your application features a complex interface, why you don’t use Prof-UIS dynamically? We can add this issue to our To-Do list to implement such configurations later (to make this a standard option) -- we are just pressed for time. But if you do plan, for some reason, to use resources in your statically linked app, then please tell us how much time we have to help you with this issue.

We need to use statically linked library because we don’t know in advance under what circumstances our application will be running. It has to be a stand-alone app. There might be a situation where your dll is already on the computer but it’s a different version which will make our app unable to run... But we really would like to use your features, the customization and the language-switching as well. By any chance will it be possible for us to build them in our app sometime this year or more like during this autumn? Thank you!

Hi,

how can I easily remove a Cmd in all dependencies like menus, toolbar, accelerators, command manager etc..?
Customization is enabled.

Thanks for your help.

Hello, how can we add and item or items, possibly a submenu, to the right click control bar context menu? Or even change it entirely?

Thanks!

Just to be clearer, the menu that lists all the bars in the app, with checkboxes next to them.
Thanks

I compiled and linked the library V2.43 with 

#define __EXT_MFC_ENABLE_TEMPLATED_CHARS

When I tried to compile my own application the following output was generated:

==== BEGIN OUTPUT ====

stdafx.cpp

Prof-UIS multiple monitor support:

built-in

Automatically linking with Prof-UIS library: ProfUIS243yud.lib

(Professional User Interface Suite)

Prof-UIS native unicode character type support:

adding automatic conversion from unsigned short to __wchar_t

Prof-UIS real wchar_t type is:

unsigned short

Client project real wchar_t type is:

native __wchar_t

c:\Programme\Prof-UIS\Include\extbutton.h(286) : error C2664: ’int CWnd::GetWindowTextW(LPTSTR,int) const’ : cannot convert parameter 1 from ’CExtSafeSimpleStringT<BaseType>::PXSTR’ to ’LPTSTR’

with

[

BaseType=__prof_uis_used_wchar_t

]

Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

 

==== END OUTPUT ====

 

Ok, I can live without _wchar_t being an internal type but I thought I might report this anyways.

Thanks

Thomas

 

Dear Support,

I would like to use customization in my application, but came to realize it’s not that easy if my app is statically linked with Prof-UIS. I made some reading here on the forum and found the answer in a message arriving in March, 2004 describing the same situation. You wrote this at that time:

<start of message>

At the moment you cannot directly use the Prof-UIS resource-dependent features in the applications statically linked with Prof-UIS.
But there is a workaround. Please follow the next steps:

Make the following changes below in the profuislib project:
1. Open the Prof-UIS workspace and make the profuislib project active;
2. Open the Prof-UIS.h file and comment the following lines:

// #if (!defined _AFXDLL || defined __STATPROFUIS_WITH_DLLMFC__) 
//     #define __EXT_MFC_NO_CUSTOMIZE 
// #endif // (defined _AFXDLL || !defined __STATPROFUIS_WITH_DLLMFC__)




3. Add the following files to the project:
    ./Include/ExtCustomize.h
    ./Include/ExtIconEditDlg.h
    ./Src/ExtCustomize.cpp
    ./Src/ExtIconEditDlg.cpp
4. Select the required configuration and build the project.

Make some changes in your application:
1. Copy the ./profuisdll/profuisdll.rc file to the project’s directory.
2. Open profuisdll.rc in the text editor, find the VS_VERSION_INFO section and remove this entire section.
3. Copy the ./profuisdll/idd_ext_color_dlg.ico file to your project’s directory.
4. Copy the contents of the ./profuisdll/res directory to your ./res directory.
5. Add the #include "profuisdll.rc" line just after the comment "Add additional manually edited resources here..." in your application’s ./res/*.rc2 file. If you do not do this, the Prof-UIS assert at startup because it is trying to access resources that are not available.
6. Copy all constant definitions from the ./profuisdll/resource.h file to your resource.h

<end of message>

I followed the steps but when I tried to compile my application (your profuislib project compiled just fine), I got a fatal resource compilation error: "#endif expected." I have found a missing #endif in your profuisdll.rc app in the English U.S resources at the commented part (the pair of "#ifndef _MAC" just before Version), but that still didn’t help, I got the same error. My app compiled successfully before.

Could you give me a reason for that? I wonder maybe version 2.40 works differently in this context than the one in March 2004.

Thank you: Chris.

Please ensure that you correctly removed the VS_VERSION_INFO section. Exactly the following lines need to be removed:

/////////////////////////////////////////////////////////////////////////////

//

// Version

//

 

VS_VERSION_INFO VERSIONINFO

 FILEVERSION 2,4,3,0

 PRODUCTVERSION 2,4,3,0

 FILEFLAGSMASK 0x3fL

#ifdef _DEBUG

 FILEFLAGS 0x1L

#else

 FILEFLAGS 0x0L

#endif

 FILEOS 0x4L

 FILETYPE 0x2L

 FILESUBTYPE 0x0L

BEGIN

    BLOCK "StringFileInfo"

    BEGIN

        BLOCK "040904b0"

        BEGIN

            VALUE "Comments", "This is part of the Professional User Interface Suite library (www.prof-uis.com)\0"

            VALUE "CompanyName", "FOSS Software, Inc.\0"

            VALUE "FileDescription", "Professional User Interface Suite DLL\0"

            VALUE "FileVersion", "2, 4, 3, 0\0"

            VALUE "InternalName", "Professional User Interface Suite DLL\0"

            VALUE "LegalCopyright", "Copyright é 2001-2005 FOSS Software, Inc.\0"

            VALUE "LegalTrademarks", "\0"

            VALUE "OriginalFilename", "ProfUIS[VersionNumber][Modifiers].dll\0"

            VALUE "PrivateBuild", "\0"

            VALUE "ProductName", "Professional User Interface Suite\0"

            VALUE "ProductVersion", "2, 4, 3, 0\0"

            VALUE "SpecialBuild", "\0"

        END

    END

    BLOCK "VarFileInfo"

    BEGIN

        VALUE "Translation", 0x409, 1200

    END

END

Hi! I’ve just compiled profuislib project again and although it compiled successfully, I got the following warning:

...

ExtTabPageContainerWnd.cpp

\Program Files\FOSS Software Inc\Prof-UIS\Src\ExtTabPageContainerWnd.cpp(939) : warning C4541: ’dynamic_cast’ used on polymorphic type ’CExtTabWnd’ with /GR-; unpredictable behavior may result

...

Could this cause the problem? I’ve checked under project->profuislib Properties... all the command line arguments under C/C++, Librarian and Browse information, but haven’t seen /GR- option... I’m really clueless now.

Thank you: Chris.

This issue was fixed in Prof-UIS 2.42. Please open the CExtTabPageContainerOneNoteWnd::PageInsert() method and replace the following lines:

CExtTabOneNoteWnd * pWndTab = 

      dynamic_cast< CExtTabOneNoteWnd * >( m_pWndTab );

with

CExtTabOneNoteWnd * pWndTab = 

      DYNAMIC_DOWNCAST( CExtTabOneNoteWnd, m_pWndTab );

I have removed all of those lines, and I’m guessing I need to remove the #ifndef _MAC line from the beginning of this section and #endif from the end of it.

I forgot to add: I’m using VS 7.1.

Thanks

We found the problem. It seems there is some conflict between the compiler and Unicode symbols when the resource file is included externally. Please open the profuisdll.rc file and remove all the language resources but those having to do with English. After this all should work fine.

All the sample code always saves the windows layout to the registry on exit - I would like to do it on command (e.g. button press).

I know that the call to ProfileBarStateSave() does the save, but I cannot take it out of DestroyWindow() and put it in say - "OnSaveLayout()", which gets called from a button press.

Specifically, the code snippet:

CWinApp * pApp = ::AfxGetApp();

ASSERT( pApp != NULL );

ASSERT( pApp->m_pszRegistryKey != NULL );

ASSERT( pApp->m_pszRegistryKey[0] != _T(’\0’) );

ASSERT( pApp->m_pszProfileName != NULL );

ASSERT( pApp->m_pszProfileName[0] != _T(’\0’) );

VERIFY(

CExtControlBar::ProfileBarStateSave(

this,

pApp->m_pszRegistryKey,

pApp->m_pszProfileName,

pApp->m_pszProfileName,

&m_dataFrameWP

);

Thanks ahead of time.

Your code snippet looks correct. It must save the bar state to the registry and can be used in your OnSaveLayout() method. Please clarify the following: "... but I cannot take it out of DestroyWindow() and put it ...". Please let us know what exactly you cannot do?

I cannot move the CExtControlBar::ProfileBarStateSave() call out of DestroyWindow() and use it in the OnSaveLayout() method. I end up with an exception in ProfileBarStateSave() at line "ASSERT( ::IsWindow(hWnd) );".


-------------------code snippet ------------------

void CMainFrame::OnSaveLayout()
{
        CWinApp * pApp = ::AfxGetApp();
        ASSERT( pApp != NULL );
        ASSERT( pApp->m_pszRegistryKey != NULL );
        ASSERT( pApp->m_pszRegistryKey[0] != _T(’\0’) );
        ASSERT( pApp->m_pszProfileName != NULL );
        ASSERT( pApp->m_pszProfileName[0] != _T(’\0’) );


            VERIFY(
                CExtControlBar::ProfileBarStateSave(
                    this,
                    pApp->m_pszRegistryKey,
                    pApp->m_pszProfileName,
                    pApp->m_pszProfileName,
                    &m_dataFrameWP
                    )
                );
    
}

Our MDI applications’ CChildFrame contains only CExtDynamicControlBar-derived classes as views into our data - there is nothing actually rendered into the child frame itself.  How do I make the dynamic control bars take up all available space within the child frame and always dock/attach on all 4 sides?

Also, the CChildFrame inherits from CMDIChildWnd and CExtDynamicBarSite, I call CExtControlBar::FrameEnableDocking(this), CExtControlBar::FrameInjectAutoHideAreas(this), and CExtDynamicBarSite::Install(this) in the CChildFrame::OnCreate method.  I also added the OnCmdMsg code in that method as well.  The docking and movement of the bars within the child frame work fine, and my [x] button will close the windows as well.  However, I get an assert fail when I try to use the "\/" button:

CExtDynamicBarSite::eDetectedUiType_t eDUIT =

pDBS->GetDetectedUiType();

if( eDUIT == CExtDynamicBarSite::__EDUIT_UNSUPPORTED_ENVIRONMENT )

{

ASSERT( FALSE );

return false;

}

 

What does this mean?

Thanks.

Well, I’m not sure what is going on.  I belive I have done everything you have asked, and it still assert-fails.  Creating the tab with the AFX_IDW_PANE_FIRST identifier makes it overlay the tool bars and the dynamic windows that are created within the child window.  Even in this configuration, I am able to move things around such that I can click on the Options button and it still assert fails.  I believe this is because the following code always returns my CView-derived class within my MDI app, rather than the tabWnd (line 22163 of extcontrolbar.cpp):

#if (!defined __EXT_MFC_NO_TAB_PAGECONTAINER_CTRL)

HWND hWndCenter =

::GetDlgItem(

pDockSite->m_hWnd,

AFX_IDW_PANE_FIRST

);

 

This makes the subsequent DYNAMIC_DOWNCAST on line 22176 of extcontrolbar.cpp return NULL, and therefore eventually cause the assert-fail.

There must be only one window with the AFX_IDW_PANE_FIRST identifier inside a CChildFrame window. Our guess there are two such windows in your child frame window: the first is the view window, the second is the tab page container window. So, you need to change the design of your child frame window. There are two solutions with regard to this:

1) Do not create a view window. You need to move all the functionality of the view window to some other place. For example, the view window can be moved into a resizable control bar.

2) (We recommend this). You can move your view window into a tab page container. Create a tab page container in your CChildFrame::OnCreate() method using the following code:

CWnd * pYourAlreadyCreatedView =
        GetDlgItem( AFX_IDW_PANE_FIRST );
    ASSERT_VALID( pYourAlreadyCreatedView );
    if( ! m_wndTabPageContainer.Create(
            this,
            CRect( 0, 0, 0, 0 ),
            AFX_IDW_PANE_FIRST
            )
        )
    {
        TRACE0("Failed to create tab page container window\n");
        return -1;
    }
    pYourAlreadyCreatedView->SetParent(
        &m_wndTabPageContainer
        );
    VERIFY(
        m_wndTabPageContainer.PageInsert(
            pYourAlreadyCreatedView->m_hWnd,
            _T("Tab item text")
            )
        );

FYI, our application is similar in appearance to the MDI_InnerOuterBars example, where there is an outer and an inner docking site.  But per your suggestions, I have switched everything to Dynamic control bars.  Your example leaves room for the colored rectangles in the middle of the MDI child frame - we would like to do away with this, as there is nothing in this area in our application.  The only views into the data appear inside the docking control bars, so we would like them to always attach on all 4 sides and leave no client area open.

Perhaps I am misunderstanding your solution to the "Options" button problem.  Our CChildFrame inherits from CMDIChildWnd and CExtDynamicBarSite.  Are you saying it should also inherit from CExtTabPageContainerWnd, or that our Applications CView-derived class should inherit from CExtTabPageContainerWnd?  Making the CView-derived class inherit from CExtTabPageContainerWnd does not appear easily done.

I tried creating a CExtTabPageContainerWnd as a member of the CChildFrame class, and Create()ing it in the OnCreate method; I also tried adding the CExtTabPageContainerWnd as a member of the CView-derived class, but both produced the same assert failure.

Can you modify the MDI_InnerOuterBars example to work with Dynamic control bars - that will probaby give me what I need.

Thanks.

Please send us an e-mail to support@prof-uis.com so we can provide you with instructions on how to download the updated source code.

You have correctly defined the base classes for your CChildFrame class. Now, create a CExtTabPageContainerWnd window with the AFX_IDW_PANE_FIRST identifier in the CChildFrame::OnCreate() method. In fact, your CChildFrame class should be similar to the CMainFrame class of the SDI_DynamicBars sample application but derived from the CMDIChildWnd class.

As for modifying the MDI_InnerOuterBars sample application: please give us one more day to code it for you.

My view does not inherit from CExtTabPageContainerWnd - I was not aware this was necessary.  I’ll try that.

How about my first question about expanding the dynamic windows to take up all available client window space?

Thanks.

We answered both your questions. If you use a tab page container inside your MDI child window, then dynamic control bars will be able to become pages inside this tab page container.

Dear support team,

 

I have a problem with data exchange feature of CDialog and derived classes. If I first add a value connection to let’s say a checkbox and then a control connection with CExtCheckBox to the same control then my initial value (bool) is cleared (always false). If I swap the lines so that first the control and then the value DDX appears everything works fine. Is there a reason for this behavior?

 

Best regards.

 

Axel

Dear sir,

I need to insert a CExtToolControlBar on a CExtResizableDialog without menu.

I use the ProfStudio sample (CProfStudioClassView) code to insert my CExtToolControlBar. But no command handlers work. No buttons are enabled.

Can you help me to know where the problem come from ?

Thanks

Is there an easy way to turn off the gradient shading in the background of CExtResizableDialog? I would like to keep the standard Windows XP background color on the dialog, but still use the resizing capabilities of CExtResizableDialog. Thanks!

I’m trying to compile new version of profuisdll but I have some errors:

In "build view" I see

ExtCmdManager.cpp
C:\Develop\Microsoft Visual Studio\VC98\INCLUDE\transact.h(226) : error C2059: syntax error : ’constant’
C:\Develop\Microsoft Visual Studio\VC98\INCLUDE\transact.h(271) : error C2143: syntax error : missing ’;’ before ’}’
C:\Develop\Microsoft Visual Studio\VC98\INCLUDE\oledb.h(17149) : error C2143: syntax error : missing ’;’ before ’}’
C:\Develop\Microsoft Visual Studio\VC98\INCLUDE\oledb.h(17149) : error C2143: syntax error : missing ’;’ before ’}’
C:\Develop\Microsoft Visual Studio\VC98\INCLUDE\oledb.h(17149) : error C2143: syntax error : missing ’;’ before ’}’

I’m using VC6 + latest platform sdk

What’s wrong?

Thanks for the answer

 

 

We would like to show you a sample from real life. We installed both Visual Studio 6.0 and Visual Studio .NET 2003 to our drive C:. Some of the exported functions of the Win32 API and Platform SDK are declared differently in older and newer SDK specifications. For example, the VarCmp() API, which is part of OLE automation, is defined in the "C:\Program Files\Microsoft Visual Studio\VC98\Include\oleauto.h" file of Visual Studio 6.0 as follows:

STDAPI VarCmp(LPVARIANT pvarLeft, LPVARIANT pvarRight, LCID lcid);

This API is defined in the "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\OleAuto.h" file of Visual Studio .NET 2003 (and any latest Platform SDK) as follows:

STDAPI VarCmp(LPVARIANT pvarLeft, LPVARIANT pvarRight, LCID lcid, ULONG dwFlags);

This example explains the source of the compilation problems. We strongly recommend you not use the latest Platform SDK with Visual Studio 6.0. It is oriented to latter versions of Visual Studio.

I use VC6 (sp6) + latest PSDK from many month and I never had problems, I’ve also compiled profuisdll 2.42.

If you see the following row you will see the include files are not in the PSDK directory but in std VC directory

ExtCmdManager.cpp
C:\Develop\Microsoft Visual Studio\VC98\INCLUDE\transact.h(226) : error C2059: syntax error : ’constant’
C:\Develop\Microsoft Visual Studio\VC98\INCLUDE\transact.h(271) : error C2143: syntax error : missing ’;’ before ’}’

I’ve configured VC order include directory, to process include PSDK directory as last, and std VC include directory as first.

 

 

What do you think about connecting to your machine remotely and trying to fix the problem dealt with this particular situation? If you do not mind, just drop us an e-mail so that we can tell you how to set up a web conference.

I don’t kwon how, but now I’ve fixed the problem.

I made the following step:

1) I’ve reinstalled version 2.40, compiled ok;

2) I ’ve updated to 2.43, compiling error;

3) I’ve compared the differencies between ExtCmdManager.h (2.40 -> 2.43) and I have commented all new lines with #define __EXT_MFC_LANG_ID_(NEW LANGUAGES). 2.43 compiled ok;

4) I’ve uncommented the same lines; compiled ok;

5) I ’ve deinstalled all and I’ve installed WinXP pro ITA (sp2), VC6 ENG(sp6), latest PSDK, 2.43, compiling error;

6) I reexecutethe step 3 again, now working fine;

I don’t knok why ...

tx

 

 

Is it possible to change the color of the grid lines in a grid ?

Is it possible to get a border around CExtEdit/CExtComboBox so they look more or less the same as the windows XP common controls?

Hi!

I have a problem concerning the PropertyGrid of version 2.43 from 15.9. - with an older version 2.43 the same code worked fine.

I have a set of general parameters. When these parameters are changed I iterate through the complete property tree and set some values to read-only, others are set to read-write, depending on the new value of the general parameters. After the style of these values has been set I call PropertyStoreSyncronize to refresh the grid. This works fine, except that the cell containing the general parameter I just changed is not updated. The value of this parameter is stored, so when I close the grid and build it again from scratch with the current values everything is displayed correctly.

Is there an alternative to PropertyStoreSyncronize to refresh the grid? An option would be an update of a single property value and its corresponding grid cell. Or is this behavior a bug in this release of Prof-UIS? Perhaps it’s even solved in a newer version...

Regards,
Torsten Ihben