Im updating ActiveDirectory from an external HR system. This system wil produce True/False values if an account is disabled or not.
I noticed (from this great forum) examples of how to combine useraccountcontrols but have a question.
If I do as Marc suggested in a previous post
const int UF_ACCOUNTDISABLE = 0x0002;
const int UF_NORMAL_ACCOUNT = 0x0200;
int userControlFlags = UF_NORMAL_ACCOUNT
newUser.Properties["userAccountControl"].Value = userControlFlags;
And alter the UF_NORMAL .. UF_ACCOUNTDISABLE according to the true/false value, will I not erase whatever other flags there was? Or do I just add another value to whatever were there in the first place? (Guess not all account is simply a matter of disabled/normal)
Regards
Not sure yet if it will work, but I think I might be able to do something like this
int uac = Convert.ToInt32(user.Properties["userAccountControl"][0]);
if (p.Active.Equals("Y"))
uac = uac | ADS_UF_ACCOUNTDISABLE;
else
uac = uac & ~ADS_UF_ACCOUNTDISABLE;
Related
I'm trying to create a way to check whether a given email (either from Outlook itself or an MSG file) is a sent, received or a draft email. I got the bit to compare if it was sent or received somewhere else and that works fine but it's the part that determines if it's a draft or not that is the issue. Below is what I have currently.
L-EMAIL = Aspose.Email.Mapi.MapiMessage:FromFile(P-FILENAME).
L-EMAIL-FLAG = Integer(L-EMAIL:Properties[Aspose.Email.Mapi.MapiPropertyTag:PR_MESSAGE_FLAGS]:ToString()).
IF L-EMAIL-FLAG = 8 THEN
L-EMAIL-STATUS = "DRAFT".
ELSE
IF L-EMAIL:Properties[Aspose.Email.Mapi.MapiPropertyTag:PR_RECEIVED_BY_ENTRYID] = ? THEN
L-EMAIL-STATUS = "SENT".
ELSE
L-EMAIL-STATUS = "RECEIVED".
If there's no attachments to the emails, it works fine since the value of a draft email is always 8 but as soon as you add attachments, it gets all weird with the values so I can't get a range down (I've gotten values like 24 and 242613 while a sent email with an attachment has a value of 49). Anyone know a smarter way of telling if it's a draft or not?
I never had a good experience working with Outlook and Progress internally... what I've managed to accomplish on my project was to create a custom DLL with C# and integrated it on my system.
So, I have an char that triggers some procedures inside my DLL and sends and receives emails (saves as .msg), making my Progress code a lot more easier to manage.
In your case, you should try something like this:
Outlook MailItem: How to distinguish whether mail is incoming or outgoing?
Solution I found was to use a C# DLL to convert the email to an Outlook mail item using the interop:
public bool IsDraft(string path)
{
Outlook.Application oApp = (Outlook.Application)Marshal.GetActiveObject("Outlook.Application");
Outlook.MailItem email = oApp.Session.OpenSharedItem(path) as Outlook.MailItem;
bool isSent = email.Sent;
Marshal.ReleaseComObject(email);
email = null;
return !isSent;
}
I had to release the email object so that code further on wouldn't break.
The PidTagMessageFlags property value is a bitmask of flags. This means a bitwise operator must be applied to check a specific flag value.
IF L-EMAIL-FLAG = 8 THEN
Please replace above line with following line of code. Hope this helps you.
IF (L-EMAIL-FLAG AND 8) = 8 THEN
I work with Aspose as Developer Evangelist.
So, if I want to write an Xll and license the code then I need a point at which to check the license file and if license is invalid then I want the Xll to stop working.
I see xlAutoOpen looks like a good place to inspect the license file. I also see that xlAutoOpen must return 1 according to the documentation, what happens if something other than 1 is returned? Can I abort the Xll opening? Can I force an unload?
Are there any better places to check the license and refuse to operate. Surely, I don't have to wait until the first worksheet function invocation.
I am unfamiliar with this framework currently so forgive newbie-ness.
EDIT: I suppose I can refuse to call xlfRegister. That will prevent operation.
EDIT2: From the Excel SDK Help file
xlAutoAdd ... can be used to ... check licensing information, for example.
Also, found that on MSDN xlAutoAdd
You should check licensing information in xlAutoOpen since this function is the first entry point to activate the XLL and is always called by Excel. If password is invalid just returns 0 to indicates failure to excel and do not register your UDFs (quit before to call xlfRegister).
I have noticed that if you register your UDFs and that you returns 0 ,
the xll is still loaded and UDFs are available, so the return
variable from xlAutoOpen does not seem to be taken into account by
Excel but by convention I believe it is better to keep returning zero
to indicate failure.
I believe MSDN doc is misleading.
xlAutoAdd is not suitable to check license since it is an optional function that is called only when the XLL is added by the Add-In Manager or when it is opened as a document (using File/Open). I assume that you may have trial licence and so that you should check it at every load time if the user's licence is still valid.
Example
Usually, you call xlAutoOpen from xlAutoAdd so your check will still be done :
pseudo code :
int __stdcall xlAutoAdd(void)
{
if(!Isinitialised)
if( xlAutoOpen() == 0) // licence check is still performed
returns 0 ;
...
MessageBoxA(GetActiveWindow(), "Thank you to install ...", "AutoOpen", MB_OK);
Isinitialised = true;
}
since xlAutoOpen is always called by Excel you should perform a similar check inside it :
bool Isinitialised = false;
int __stdcall xlAutoOpen(void) // Register the functions
{
if(Isinitialised)
return 1;
if(!ValidLicense()) // check licence in xlAutoOpen
return 0;
// continue initialization , registration ..
.....
Isinitialised = true;
}
Finally note that you can omit xlAutoAdd because it has no adverse consequences and is not required by Excel. Personally I do not use this function.
I have a simple custom table in AX, for which i need to create a Web service so that data could be populated by an external system. I created a Document service with all the Axd* and Ax* objects involved. Next i wrote a simple console application to try populating some dummy data. Interesting thing is i can only get string data type columns populated. Int, Real, Date, Enums etc are not coming through.
In the code below, i am only getting StoreItemId and Barcode columns, as both are strings. Cost is real, ErrorType is Enum, DocketDate is date and none of them get any values. I have discussed this issue with many colleagues and none is aware whats happening. Does anyone know or could point me in some new direction? Thanks a lot.
PS - I have limited experience with AIF and if i am missing something fundamental, please excuse and do let me know. Thanks.
AxdEntity_MMSStagingSalesImport stagingSalesImport = new AxdEntity_MMSStagingSalesImport();
stagingSalesImport.StoreItemId = "9999";
stagingSalesImport.Barcode = "1234546";
stagingSalesImport.Cost = 22;
stagingSalesImport.ErrorType = AxdEnum_MMSImportErrorType.Posting;
stagingSalesImport.DocketDate = new DateTime(2014, 4, 4);
stagingSalesImport.IsDuplicate = AxdEnum_NoYes.Yes;
For some types, you have to specify that you have set the values, so that AX knows the difference between a null value and a value that is set:
stagingSalesImport.Cost = 22;
stagingSalesImport.CostSpecified = true;
stagingSalesImport.ErrorType = AxdEnum_MMSImportErrorType.Posting;
stagingSalesImport.ErrorTypeSpecified = AxdEnum_MMSImportErrorType.Posting;
Thanks for replying Klaas, i like your blog as well.
Should have responded earlier but i fixed the issue.
I didn't try Klaas's option but i had a look at the data policies for the inbound port and found that none of the columns were enabled. I enabled the ones i needed and made most of them required as well. And guess what, that worked. I was expecting that the columns should have been enabled by default.
I have a super simple select in a wcf service like
BusinessModel.Candidate candidateObject
= dcMUPView.Candidates.SingleOrDefault(dev => dev.Username == username);
But when I hit this code, and then check the candidateObject, it's candidateid value is incorrect. In the DB candidateid is the identity column and primary key. In this case it is 2572884 in the DB but when I look in the candidateObject is says the value returned is something like 0x00274254. Anyone know what might cause something like this?
I think your query is returning the correct record, since 0x00274254 (base 16) = 2572884 (base 10).
If you are checking the value using the debugger, make sure you have the Hexadecimal Display option turned off (see here for more info: Visual Studio debugger - Displaying integer values in Hex).
Hey, I am making some stuff in Objective-C++... And I must say that I am a total newbie when it comes to the Objective-C part... I don't really want to learn it, I kinda just need it for accessing a few Mac APIs (ObjC is such a dumb language).
So - compiling with g++ -x objective-c++ - and I somehow keep getting this warning:
XXX may not respond to YYY
First it was with a NSScreen, now it is with a NSWindow:
NSWindow may not respond to +initWithContentRect:styleMask:backing:defer:
I saw somewhere that I should cast it to id, but didn't work, throwing absolutely cryptic errors...
So - WHAT does this warning actually mean and HOW am I supposed to make it stop?
EDIT: Okay, apparently I need to ALLOCATE an instance first, then I can call its init function... Anyways, now the GCC is reporting:
confused by earlier errors, bailing out
And NOTHING else. This is the ONLY error that it reports. I figured that there is some error in my code that doesn't get reported... So I will post the whole file where the problem is here:
ONXeWindow::ONXeWindow(int px, int py, int sw, int sh, bool resizable){
NSRect wr = NSMakeRect(px, py, sw, sh);
int wf = 1; // titled
wf += 2; // closable
wf += 4; // miniaturizable
wf += (resizable ? 8 : 0); // resizable
wf += (false ? 128 : 0); // metal bg
useWindow = [[NSWindow alloc] initWithContentRect:wr styleMask:wf backing:2 defer:YES];
}
Also, YES, framework AppKit was imported (in the header file) - I am not going to confuse you with my weird file scheme here.
The message isn't really cryptic, you just don't know the language (and don't care to, by your own admission).
Since Objective-C methods are dispatched dynamically at run-time, you can call a method that the compiler doesn't have any knowledge of, however, the compiler is warning you that you're doing so. The + in the beginning of the method name means that you're calling a class method (a - would indicate that you're calling a method on an instance). Since NSWindow has no class method named initWithContentRect:styleMask:backing:defer:, the compiler is giving you a warning, and in this case, it's a pretty good one.
You probably wrote something like:
NSWindow* myWindow = [NSWindow initWithContentRect:rect styleMask:0 backing:0 defer:NO];
when you meant to write something like:
NSWindow* myWindow = [[NSWindow alloc] initWithContentRect:rect styleMask:0 backing:0 defer:NO];
The first one sends the message directly to the class, but this is an instance method. You need to allocate an instance of NSWindow first, then send the init message. Also, clang tends to give much better warning and error messages than gcc. Clang 2.0 also handles C++ and ObjC++ pretty well, so it might be worth it to switch to clang.
Checkout this example, looks like you are not allocating your objects.