The call NCryptOpenStorageProvider(myProvider, MS_KEY_STORAGE_PROVIDER, 0) returns 0x800706D9. Since I couldn't find this retcode in MSDN, I am really in a mess. What went wrong?
Related
My code is below.
But after returning, an error of'Unreachable code' occurs in holy.
I want to fix
I am Korean and I used a translator
act = [i for i in acts if isinstance(i, discord.CustomActivity)]
if act:
act = act[0]
else:
return
text = str(act.name)
if text:
holy = (f'상태메시지 : {text}')
else:
return
holy = ('상태메시지가 없습니다')```
In functions, return returns a value from the function and stops the function. So any code you write after typing return is unreachable. That's why you're getting this error. Your question doesn't contain much code, but as far as I can see, you can define the variable holy above return.
In order-detail.tpl, there are variables such as {$is_guest} and {$return_allowed}. A little debugging (using Javascript alert) shows that {$is_guest} is undefined for some reason and {$return_allowed} returns 0 even though I allowed returns. This is leading to the order-detail page hiding merchandise return section.
All these Smarty variables are defined in root/controllers/OrderDetailController.php, so I don't know what's causing the errors.
I'm using Prestashop 1.4.9. Any help is greatly appreciated. Thank you!
I solved my own question. Go to root/controllers/OrderDetailController.php. Around line 144, change
'is_guest' => false,
to
'is_guest' => "false",
And also, change
{if !$is_guest}
to
{if $is_guest == "false"}
As for $return_allowed, it turns out that the items must be marked as delivered first in the BO. It is defined such that it is false unless paid for + delivered + before return deadline.
I'm unable to get this function to work. The if always return false. What i'm doing wrong?
This come from a cocoa checkbox, the OverrideBuildCheked is 1 when checked and 0 when unchecked.
on OverRideBuildNumber_(sender)
set OverrideBuildCheked to CurrentBuildOverrideChk's state
if OverrideBuildCheked = 1 then
CurrentBuildField's setEnabled_(true)
CurrentBuildField's setEditable_(false)
else
CurrentBuildField's setEnabled_(false)
CurrentBuildField's setEditable_(true)
end if
end OverRideBuildNumber_
Just about everything from Cocoa is a pointer to an object (you can see this by logging the result), so you usually need to coerce to the desired AppleScript class, e.g. CurrentBuildOverrideChk's state as integer (or boolean).
Why is it that when I call RtlDosPathNameToNtPathName_U on the path \\?\C:, instead of getting back
\??\C:
I get back
\??\C:\\\?\C:
which is clearly incorrect?
Code snippet (in D):
struct CurDir { UnicodeString DosPath; HANDLE Handle; }
extern (Windows) static bool RtlDosPathNameToNtPathName_U(
in const(wchar)* DosPathName, out UnicodeString NtPathName,
out const(wchar)* NtFileNamePart, out CurDir DirectoryInfo);
wchar[] toNtPath(const(wchar)[] path)
{
UnicodeString ntPath;
CurDir curDir;
const(wchar)* fileNamePart;
enforce(RtlDosPathNameToNtPathName_U(path.ptr, ntPath,
fileNamePart, curDir));
try
{ return ntPath.Buffer[0 .. ntPath.Length / ntPath.Buffer[0].sizeof].dup; }
finally { RtlFreeHeap(RtlGetProcessHeap(), 0, ntPath.Buffer); }
}
writeln(toNtPath(r"\\?\C:")); //Returns the weird string
Update:
I figured out the problem -- see my answer.
RtlDosPathNameToNtPathName_U is giving you the correct output. The reason you see a weird-looking character in the middle is because UNICODE_STRINGs are not required to be null-terminated (which I'm sure you know already). The file name \??\C:\ is a completely valid native-format file name. I suspect what you really want is to prepend the device name instead of just referring to the GLOBAL?? directory like what RtlDosPathNameToNtPathName_U has done.
To do that, simply call NtQuerySymbolicLinkObject on \??\x:, where x is the drive letter that the path is using, and prepend the result. If it's a UNC path, prepend \Device\Mup. And so on for the other types of paths (if there are any).
I figured out the problem myself, with #wj32's help: I'd totally forgotten that the input to RtlDosPathNameToNtPathName_U needed to be null-terminated, and my code didn't handle that properly. Thanks for everyone's help!
I'm banging my head against the wall on this one. I was looking at some old database reporting code written in VB6 and came across this line (the code is moving data from a "source" database into a reporting database):
rsTarget!VehYear = Trim(Str(rsSource!VehYear))
When rsSource!VehYear is Null, the above line generates an "Invalid use of Null" run-time error. If I break on the above line and type the following in the Immediate pane:
?rsSource!VehYear
It outputs Null. Fine, that makes sense. Next, I try to reproduce the error:
?Str(rsSource!VehYear)
I get an "Invalid use of Null" error.
However, if I type the following into the Immediate window:
?Str(Null)
I don't get an error. It simply outputs Null.
If I repeat the same experiment with Trim() instead of Str(), everything works fine. ?Trim(rsSource!VehYear) returns Null, as does ?Trim(Null). No run-time errors.
So, my question is, how can Str(rsSource!VehYear) possibly throw an "Invalid use of Null" error when Str(Null) does not, when I know that rsSource!VehYear is equal to Null?
Update: If I type the following in the Immediate window, it works as expected (no error occurs):
?Str(rsSource!VehYear.Value)
This outputs Null. Now, I know that rsSource!VehYear is actually an ADODB.Field instance, but Value is its default property, so Str should be operating on the Value property (which is Null). Even the error message ("Invalid use of Null") suggests that Str is receiving a Null parameter, but how can it treat Null differently in one case and not the other?
My only guess is the internal implementation of Str() is somehow failing to get the default property, and the "Invalid use of Null" error is happening for a different reason (something other than the parameter is causing the "Invalid use of Null", perhaps when it is trying to retrieve the default property from the Field object).
Does anyone have a more detailed, technical explanation for what is actually happening here?
In short:
?Str(rsSource!VehYear)
throws an "Invalid use of Null" error when rsSource!VehYear is Null, but
?Str(rsSource!VehYear.Value)
returns Null.
However, both Trim(rsSource!VehYear) and Trim(rsSource!VehYear.Value) return Null.
If you need a value other than a string, try using IsNull instead:
rsTarget!VehYear = IIf(IsNull(rsSource!VehYear), 0, rsSource!VehYear)
' Note 0 is the default value
The Str function will specifically check if a Null value is passed in and deal with it accordingly. When you pass in an object it attempts to convert the result of a default method to a String. The result of the default method is not passed into the Str method, but Field object is, so a check for the initial Null will fail. The Str function will continue to check the parameter type for datatypes that it supports when it realizes that it has an object, it will attempt to retrieve the default value. It doesn't re-attempt to deal with the default value as it did with the passed in argument, so the attempt to return a Null as a String will fail. It seems MS didn't expect a default value to be Null or any other invalid value for Str. For instance Str doesn't support an empty string either.
This was my workaround in the vb6-days:
rsTarget!VehYear = Trim(Str(rsSource!VehYear & ""))
the & "" will make sure there is allways at least an empty string to work with.
From memory, null database fields are Nothing (or possibly vbNull), which do not have the same rules applied to them as Null. You should just be able to do a quick check:
If (rsSource!VehYear Is Nothing) Then
' Null
Else
' Not null
End If