C / C++ / MFC

BillingDates *bData; // the class is called BillingDates not BillingData
BillingDates bData2;

bData = new BillingDates("someFilename");

bData = new BillingDates("someFilename");

someclass someclassob {get;set;}

someclassobj = new someclass("Parameter goes here");

pkfox wrote:

ypu can declare like

someclass someclassob {get;set;}

class BillingDates
{
public:
    BillingDates();
    BillingDates(std::string InputFile);
    void addFile(std::string InputFile);
    void ProcessDates();
// stuff removed for readability
};
// the implementation of addFile will do the same as the constructor that takes a filename.

BillingDates *bData;
BillingDates bData2;

// and later on something like
bData2.addFile("your file name here");
bData = &bData2;

BillingDates *bData;

// and later on something like

bData = new BillingDates("your file name here");

The target window (CTreeCtrl) is returning on the OnDragEnter and OnDragOver a DROPEFFECT_NONE.  The cursor is displaying as if I returned a DROPEFFECT_COPY.  I can return back other types like DROPEFFECT_MOVE or DROPEFFECT_LINK and those behave properly.  The interesting thing is that OnDrop is not called if I do return DROPEFFECT_NONE, and it is called in the case I do DROPEFFECT_MOVE, etc.  So the function calling is correct.  It is only the cursor that is being displayed that is not correct.  Also in this same application within other windows, I am using other implementations (different window types) of COLEDropTarget and the cursor behavior is correct.  I have no clue where else to look at this time.  As a workaround, I'm using the CImageList Drag concept to display a NOT symbol beside the cursor when DROPEFECT is NONE.

printf("\tPlatform: %d\n", pTmpBuf->sv101_platform_id);
wprintf(L"\tName:     %s\n", pTmpBuf->sv101_name);
printf("\tVersion:  %d.%d\n",
       pTmpBuf->sv101_version_major,
       pTmpBuf->sv101_version_minor);
printf("\tType:     %d", pTmpBuf->sv101_type);

   Platform: 500
        Name:     MACMINI-558088
        Version:  6.1
        Type:     4099

        Platform: 500
        Name:     WIN1019H2X64
        Version:  10.0
        Type:     4099

where macmini is a mac system.

#define SV_TYPE_APPLE_MINI_CUSTOM_TYPE 0x123456789 

default_server_announce = 0;
default_server_announce |= SV_TYPE_WORKSTATION;
default_server_announce |= SV_TYPE_SERVER;
default_server_announce |= SV_TYPE_SERVER_UNIX;
default_server_announce |= SV_TYPE_PRINTQ_SERVER;

switch (lp_announce_as())
{
    case ANNOUNCE_AS_NT_SERVER:
    {
        default_server_announce |= SV_TYPE_SERVER_NT;
        /* fall through... */
    }
    case ANNOUNCE_AS_NT_WORKSTATION:
    {
        default_server_announce |= SV_TYPE_NT;
        break;
    }
    case ANNOUNCE_AS_WIN95:
    {
        default_server_announce |= SV_TYPE_WIN95_PLUS;
        break;
    }
    case ANNOUNCE_AS_WFW:
    {
        default_server_announce |= SV_TYPE_WFW;
        break;
    }
    default:
    {
        break;
    }
}

I am using the NetServerEnum function to enumerate the network and printing all records. But I'm getting the same SV type for MAC OS system and Windows10 system. Also, sv101_version_major and sv101_version_minor are wrong. Kindly let me know how this function works, and from where I am getting these values. What is the limitation of this API.

printed logs using the provided example is:

NetServerEnum(pszServerName,
dwLevel,
(LPBYTE *) & pBuf,
dwPrefMaxLen,
&dwEntriesRead,
&dwTotalEntries,
dwServerType,
pszDomainName,
&dwResumeHandle);

//Printing logs:
printf("\tPlatform: %d\n", pTmpBuf->sv101_platform_id);
wprintf(L"\tName: %s\n", pTmpBuf->sv101_name);
printf("\tVersion: %d.%d\n",
pTmpBuf->sv101_version_major,
pTmpBuf->sv101_version_minor);
printf("\tType: %d", pTmpBuf->sv101_type);

Output=>

Platform: 500
Name: MACMINI-558088
Version: 6.1 //<==VERSION is common among both UNIX and MAC
Type: 4099 //<==SAME SV_TYPE
Platform:500
Name: MAILSRV
Version: 6.1 //<==VERSION is common among both UNIX and MAC
Type: 8493571
Platform:500
Name: WIN1019H2X64
Version: 10.0
Type: 4099 //<==SAME SV_TYPE

Where macmini is MAC and mailsrv is Unix system. sv_type of macmini and WIN1019H2X64 is the same. sv101_version_major and sv101_version_minor are the same for UNIX and MAC systems, which use SAMBA. Kindly let me know why it is? So I can differentiate these systems using predefined macros in lmserver.h.

Member 14117853 wrote:

Kindly let me know how this function works, and from where I am getting these values.

Member 14117853 wrote:

sv101_version_major and sv101_version_minor are the same for UNIX and MAC systems, which use SAMBA. Kindly let me know why it is?

[announce as]
This specifies what type of server nmbd(8) will announce itself as, to a network neighborhood browse list. By default this is set to Windows NT. The valid options are : "NT Server" (which can also be written as "NT"), "NT Workstation", "Win95" or "WfW" meaning Windows NT Server, Windows NT Workstation, Windows 95 and Windows for Workgroups respectively. Do not change this parameter unless you have a specific need to stop Samba appearing as an NT server as this may prevent Samba servers from participating as browser servers correctly.

Default: announce as = NT Server

Example: announce as = Win95

[announce version]
This specifies the major and minor version numbers that nmbd will use when announcing itself as a server. The default is 4.9. Do not change this parameter unless you have a specific need to set a Samba server to be a downlevel server.

Default: announce version = 4.9

Example: announce version = 2.0