If you want to represent a value larger than 32bits in an enum in MSVC++ you can use C++0x style syntax to tell the compiler exactly what kind of integral type to store the enum values. Unfortunately by default an enum is always 32bits, and additionally while you can specify constants larger than 32bits for the enum values, they are silently truncated to 32bits.
For instance the following doesn't compile because Lorem::a and Lorem::b have the same value of '1':
enum Lorem {
a = 0x1,
b = 0x100000001
} val;
switch (val) {
case Lorem::a:
break;
case Lorem::b:
break;
}
Unfortunately it is not an error to have b's constant truncated, and the previous without the switch statement does compile just fine:
enum Lorem {
a = 0x1,
b = 0x100000001
} val;
But you can explicitly specify that the enum should be represented by a 64bit value and get expected compiling behavior with the following:
enum Lorem : UINT64 {
a = 0x1,
b = 0x100000001
} val;
switch (val) {
case Lorem::a:
break;
case Lorem::b:
break;
}
In JavaScript numbers are 64bit floating point numbers which have 53 bits of mantissa. That means you can accurately represent [-2^53, 2^53] as integers in JavaScript. Aka [-9007199254740992, 9007199254740992].
I've hooked up the printer/scanner to the Media Center PC since I leave that on all the time anyway so we can have a networked printer. I wanted to hook up the scanner in a somewhat similar fashion but I didn't want to install HP's software (other than the drivers of course). So I've written my own script for scanning in PowerShell that does the following:
Here's the actual code from my scan.ps1 file:
param([Switch] $ShowProgress, [switch] $OpenCompletedResult)
$filePathTemplate = "C:\users\public\pictures\scanned\scan {0} {1}.{2}";
$time = get-date -uformat "%Y-%m-%d";
[void]([reflection.assembly]::loadfile( "C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll"))
$deviceManager = new-object -ComObject WIA.DeviceManager
$device = $deviceManager.DeviceInfos.Item(1).Connect();
foreach ($item in $device.Items) {
$fileIdx = 0;
while (test-path ($filePathTemplate -f $time,$fileIdx,"*")) {
[void](++$fileIdx);
}
if ($ShowProgress) { "Scanning..." }
$image = $item.Transfer();
$fileName = ($filePathTemplate -f $time,$fileIdx,$image.FileExtension);
$image.SaveFile($fileName);
clear-variable image
if ($ShowProgress) { "Running OCR..." }
$modiDocument = new-object -comobject modi.document;
$modiDocument.Create($fileName);
$modiDocument.OCR();
if ($modiDocument.Images.Count -gt 0) {
$ocrText = $modiDocument.Images.Item(0).Layout.Text.ToString().Trim();
$modiDocument.Close();
clear-variable modiDocument
if (!($ocrText.Equals(""))) {
$fileAsImage = New-Object -TypeName system.drawing.bitmap -ArgumentList $fileName
if (!($fileName.EndsWith(".jpg") -or $fileName.EndsWith(".jpeg"))) {
if ($ShowProgress) { "Converting to JPEG..." }
$newFileName = ($filePathTemplate -f $time,$fileIdx,"jpg");
$fileAsImage.Save($newFileName, [System.Drawing.Imaging.ImageFormat]::Jpeg);
$fileAsImage.Dispose();
del $fileName;
$fileAsImage = New-Object -TypeName system.drawing.bitmap -ArgumentList $newFileName
$fileName = $newFileName
}
if ($ShowProgress) { "Saving OCR Text..." }
$property = $fileAsImage.PropertyItems[0];
$property.Id = 40092;
$property.Type = 1;
$property.Value = [system.text.encoding]::Unicode.GetBytes($ocrText);
$property.Len = $property.Value.Count;
$fileAsImage.SetPropertyItem($property);
$fileAsImage.Save(($fileName + ".new"));
$fileAsImage.Dispose();
del $fileName;
ren ($fileName + ".new") $fileName
}
}
else {
$modiDocument.Close();
clear-variable modiDocument
}
if ($ShowProgress) { "Done." }
if ($OpenCompletedResult) {
. $fileName;
}
else {
$result = dir $fileName;
$result | add-member -membertype noteproperty -name OCRText -value $ocrText
$result
}
}
I ran into a few issues:
(long*)
to a (long)
you get a W4 warning. However, the #defines are still set for 32bit builds. This means that other parts of
the code can make assumptions based on the #defines that are valid on 32bit but generate 64bit errors or warnings....
#ifdef _WIN64
...
WINUSERAPI
LONG_PTR
WINAPI
SetWindowLongPtrA(
__in HWND hWnd,
__in int nIndex,
__in LONG_PTR dwNewLong);
...
#else /* _WIN64 */
...
#define SetWindowLongPtrA SetWindowLongA
...
#endif /* _WIN64 */
...
In 64bit everything's normal but in 32bit SetWindowLongPtrA is #defined to SetWindowLongA which takes a LONG rather than a LONG_PTR. So take the following code snippet:
...
LONG_PTR inputValue = 0;
LONG_PTR error = SetWindowLongPtrA(hWnd, nIndex, inputValue);
...
This looks fine but generates warnings with the Wp64 flag.