How to get window main handle?

My code is as follows:


#include <Mstn\MdlApi\MdlApi.h>
#include <Mstn\cmdlist.r.h>
#include <Mstn\MdlApi\msnativewindow.h>
#include <windows.h>
#include <DgnPlatform\DgnFile.h>
#include <DgnPlatform\DgnFileIO\DgnFileIOApi.h>

extern "C" DLLEXPORT void MdlMain(int argc, WCharCP argv[])
{
             HWND hWnd = NULL;
             hWnd = (HWND)mdlNativeWindow_getMainHandle(0);


            return;

}

I can't able to resolve these build errors.

Parents Reply Children
  • Now i have moved  windows.h to top of include.

    Sorry, but it's not the real solution. It looks like "let's try to change something and let's hope it will work".

    Likely the problem was not solved, but just hidden or postponed, and will return back later.

    When there is conflict with types declarations, in parallel to how and what headers are used, it's important to use namespaces properly. I do not see anything like this in your code.

    Now I am unresolved external symbols error.

    And? Did you solve it? Did your learn what this error means? It's standard (and often received) C++ linker information.

    What MicroStation libraries do you link?

    Plus, when you will search this forum, this error was discussed many times already.

    "bmake -a +dCcompOpts=-showIncludes hc_microstation"

    It's weird, because I would assume that complete headers pre-processing list will be displayed. But maybe your makefile swallows the passed argument, because evidently it's not passed to cl.exe compiler.

    Regards,

      Jan

  • Hi ,

    1. Bmake Compile errors.  Do you have nativewindow.lib in your LINKER_LIBRARIES list in your project mke file?
    2. Visual Studio Compiler Warning (screen capt hilight).
      1. The MicroStation CONNECT SDK developer shell (currently) required Microsoft 8DOT3NAMES to be enabled.  This long standing requirement unfortunately is in direct conflict with Microsoft's IntelliSense current capabilities and is known to cause issues; like your warning and IntelliSense being able to perform: Peek/Go To Definitions/Declarations.  Since it is not likely Microsoft will add support for a legacy requirement like 8DOT3NAMES to IntelliSense, I am working towards:
        1. Updating the developer shell to provide IntelliSense unmangled (full path) names (shooting for next release - U16)
        2. Verify all required tools in our build chain work similarly
        3. Update all SDK Examples to build w/o 8DOT3NAME requirements, and lastly...
        4. Create a wiki on: How to Update Bentley Make Files and Remove 8DOT3NAME Requirements.
      2. Although there is another coding hack/work-around, it is probably best to simply choose to dismiss the IntelliSense compiler warning by:
        1. Go to your Visual Studio Project's - Error List
        2. Change - From: "Build + IntelliSense", To: "Build"

    HTH,
    Bob



  • C++ Standard Library

    We used windows.h for using some of windows functionality such as STL

     The Standard Template Library (STL) has nothing to do with Windows.  These days it's part of your C++ compiler installation.  This article may throw some light.

     
    Regards, Jon Summers
    LA Solutions

  • And? Did you solve it? Did your learn what this error means? It's standard (and often received) C++ linker information.

    What MicroStation libraries do you link?

    Hi Jan,

    No, I am still facing this issue. 

    #---------------------------------------------------------------------------------------+
    #
    #    $Source: hc_microstation.mke $
    # 
    #    $Copyright: (c) 2017 Bentley Systems, Incorporated. All rights reserved. $
    #
    #---------------------------------------------------------------------------------------+
    PolicyFile = MicroStationPolicy.mki
    
    appName     =  hc_microstation
    sAppName    =  hc_microstation
    
    MDLMKI = $(MSMDE)mki/
    mdlLibs = $(MSMDE)library/
    hc_out = D:/Repository/microstation_main/bin/x64/Release/
    
    dirToSearch = $(MDLMKI)
    
    genSrc = $(o)
    
    %include $(MDLMKI)mdl.mki 
    
    #--------------------------------------------------------------------------------------
    #    Create needed output directories in case they don't exist
    #--------------------------------------------------------------------------------------
    always:
        !~@mkdir $(o)
        !~@mkdir $(rscObjects)
        !~@mkdir $(reqdObjs)
    
    dirToSearch = $(o)
    %include cincapnd.mki
    
    #--------------------------------------------------------------------------------------
    #    Define macros specific to this example
    #--------------------------------------------------------------------------------------
    privateInc      = $(baseDir)
    langSpec        = $(baseDir)transkit/
    
    libRscs = \
        $(rscObjects)$(sAppName).rsc
    
    #--------------------------------------------------------------------------------------
    #    Create object files
    #--------------------------------------------------------------------------------------
    $(rscObjects)$(sAppName).rsc     : $(baseDir)$(sAppName).r
    
    $(o)$(sAppName).h                : $(baseDir)$(sAppName).r
    
    #--------------------------------------------------------------------------------------
    #    Set up to use dlmcomp.mki and dlmlink.mki
    #--------------------------------------------------------------------------------------
    
    DLM_NAME                = $(appName)
    DLM_DEST                = $(mdlapps)
    DLM_OBJECT_FILES        = $(o)$(appName)$(oext)
    DLM_OBJECT_DEST         = $(o)
    DLM_LIBDEF_SRC          = $(_MakeFilePath)
    DLM_SPECIAL_LINKOPT     = -fixed:no     # Notify linker this library does not require a fixed base address to load
    DLM_NO_DLS              = 1             # USE DLLEXPORT IN .CPP
    DLM_NO_DEF              = 1
    DLM_NOENTRY             = 1
    DLM_NO_MANIFEST         = 1             # If not set linker embeds your current (developer) patched MSVCRT version manifest in output dll.  This is not desirable and produces side-by-side CLIENT ERROR: 14001)
    DLM_NO_SIGN             = 1             # If not set and no certificate found, ERROR: 'singleton' is not recognized as an internal or external command
    DLM_NO_INITIALIZE_FUNCTION  = 1
    
    LINKER_LIBRARIES + $(mdlLibs)bentley.lib
    LINKER_LIBRARIES + $(mdlLibs)mdlbltin.lib
    LINKER_LIBRARIES + $(mdlLibs)BentleyGeom.lib
    LINKER_LIBRARIES + $(mdlLibs)DgnPlatform.lib
    LINKER_LIBRARIES + $(mdlLibs)dgnview.lib
    LINKER_LIBRARIES + $(mdlLibs)RmgrTools.lib
    LINKER_LIBRARIES + $(mdlLibs)BentleyAllocator.lib
    LINKER_LIBRARIES + $(hc_out)hc.shield.lib
    LINKER_LIBRARIES + $(hc_out)hc.ui.lib
    
    
    #--------------------------------------------------------------------------------------
    #    Compile the source files for the DLM
    #--------------------------------------------------------------------------------------
    $(o)$(appName)$(oext)       : $(baseDir)$(appName).cpp
    
    %include $(MDLMKI)dlmlink.mki
    
    #--------------------------------------------------------------------------------------
    #    Merge the dialog resources & MDL program file using rlib
    #--------------------------------------------------------------------------------------
    $(reqdObjs)$(appName).mi        : $(libRscs)
        $(msg)
        > $(o)make.opt
        -o$@
        $(libRscs)
        <
        $(RLibCmd) @$(o)make.opt
        ~time
    
    #--------------------------------------------------------------------------------------
    #    complete construction of the .ma
    #--------------------------------------------------------------------------------------
    libRscs = \
        $(reqdObjs)$(appName).mi
    
    $(mdlapps)$(appName).ma : $(libRscs)
            $(msg)
            > $(rscObjects)make.opt
            -o$@
            $(libRscs)
            <
            $(RLibCmd) @$(rscObjects)make.opt
            ~time

    I have gone through many forums but still i am stuck.

    Is there anything library need to include??

    Regards,

    Rajesh

  • Hi Robert,

    Bmake Compile errors.  Do you have nativewindow.lib in your LINKER_LIBRARIES list in your project mke file?

    Yes i have included our native window lib in mke file.


    Although there is another coding hack/work-around, it is probably best to simply choose to dismiss the IntelliSense compiler warning by:
    1. Go to your Visual Studio Project's - Error List
    2. Change - From: "Build + IntelliSense", To: "Build"

    I tried by changing Error list to Build only. But still i am facing unresolved  external symbol error.

    Regards

    Rajesh

  • Hi Rajesh,

    No, I am still facing this issue. 

    it's because you do not follow my and Bob's advises.

    • Me (general advice): What MicroStation libraries do you link?
    • Bob (specific advice): Bmake Compile errors.  Do you have nativewindow.lib in your LINKER_LIBRARIES list in your project mke file?
    Is there anything library need to include??

    It's C++ rule that for every function or class used, you have to ensure proper library will be linked. So when you use mdlNativeWindow_getMainHandle(), you have to link the proper library. And Bob already told you it's nativewindow.lib, but I do not see this library in your makefile.

    You do not share output from bmake process (not what Visual Studio shows you, but what bmake reports when started manually). Maybe you even do not try to understand what compiler and linker tell you? I can guess only, but I assume the linker complains in this way (output for another project and another missing lib):

    ElementsExampleQueryTool.obj : error LNK2001: unresolved external symbol 
    "protected: virtual void __cdecl Bentley::DgnPlatform::DgnElementSetTool::_ModifyAgendaEntries(void)"
    (?_ModifyAgendaEntries@DgnElementSetTool@DgnPlatform@Bentley@@MEAAXXZ)

    which tells exactly error id (so can be searched in this forum and on Internet) and also what class or method cannot be linked (so documentation can be consulted, or when the information is not found, tools like dllexp or dumpbin can be used to find the right library).

    but still i am stuck.

    I think the main problem that is that without proper C++ development skills (and C++ is known as not only complicated language, but also language with very complex requirement for build process) you try to start with MicroStation app development (which adds extra levels of complexity on top of C++), where to know all details how C++ works is mandatory.

    It's like to learn how to drive car after injury and surgery, without finished convalescence and physiotherapy, trying to learn traffic rules and legal context during driving, not before. Ignoring the process "one step after another" never leads do good and efficient results.

    My code is as follows:

    Now I have noticed ... did you think about your code?

    I have no idea what will happen, I do not think you will receive any valid handle before you switch MicroStation to graphics mode. Is there any "main windows" when MicroStation is not in graphics mode?

    Regards,

      Jan

  • The project still fails to compile

    Incorrect!  His project compiles OK.

    Building a C++ project takes several steps...

    1. Compile MicroStation resources (command tables, dialogs, message lists etc)
    2. Compile Windows resources (message lists, version info etc)
    3. C++ pre-processor
    4. Compile C++ code
    5. Link

    Examine his build log to see this...

         Creating library C:\Users\RVARAT~1\AppData\Local\Temp\Bentley\MicroStationSDK\objects\hc_microstation.lib and object C:\Users\RVARAT~1\AppData\Local\Temp\Bentley\MicroStationSDK\objects\hc_microstation.exp
    hc_microstation.obj : error LNK2019: unresolved external symbol mdlNativeWindow_getMainHandle referenced in function MdlMain
    C:\PROGRA~1\Bentley\MICROS~1\MICROS~1\mdlapps\hc_microstation.dll : fatal error LNK1120: 1 unresolved externals
    

    The log is telling you that function mdlNativeWindow_getMainHandle() is used, but the linker can't find its implementation.  The implementation is in a library (*.lib) file, but that's not specified in his bmake file.

     
    Regards, Jon Summers
    LA Solutions

  • The project still fails to compile.

    It is not clear what you mean by "the project", because the discussion is nearly year old.

    But if you mean the discussed project, discussed by Rajesh, I agree with Jon: The compilation was ok, because the error message was not reported by compiler, but by linker.

    Do you understand the whole application build process (well described by Jon)?

    Unfortunately, this old discussion stopped in a middle, and no requested information was shared, so I guess no final conclusion was done at this time.

    "Unable to find/link library" and "Unable to find external symbol" are one from the most often reported C/C++ code build errors in my opinion, when to know and analyze complete environment is usually required.

    With regards,

      Jan