I've got some difficulties to understand the following declaration in VC++:
int numChoice=figureCB->SelectedIndex;//CB=COMBO BOX
char Choice=((String^) figureCB->Items[numChoice])[0];//
It's the second line that causes me the problem. Why is 'String^' in brackets?
Why is:
char Choice=(String^ figureCB->Items[numChoice])[0];//
uncorrect?
Usually, when I declare a pointer on a class, I write:
ClassName *pointername;
or, when it points to a managed class:
ClassName ^pointername;
This is CLI code, not pure C++, (what you have called 'managed').
The brackets are a cast.
Related
In VBA Debug.Print prints to the Immediate window.
I just found out that using a semicolon (;) makes it print at the position of the caret/text cursor which seems odd.
Debug.Print "a" & "b" & "c"
Debug.Print ; "a"; "b"; "c"
Debug.Print "a", "b", "c"
Prints the following.
abc
abc
a b c
That was my main question before I found it in the documentation and understood it a little more.
Use a semicolon (;) to position the insertion point immediately following the last character displayed.
My question now is if it is possible to use a named argument like this:
Debug.Print object:="..."
Intellisense usually helps finding the arguments' names but it doesn't list any.
I also tried object or outputlist like it shows in the docs but it throws an error.
Is Debug.Print different in that regard?
Debug statements are indeed different from everything else. If you look for a Debug module in the Object Browser, you won't find it, even with hidden classes and members shown.
Debug.Print and Debug.Assert statements are literally baked into the language [parser] itself - the comma here doesn't mean "argument separator", instead it's a special-form syntax that is [apparently] reserved for Print methods (note: VBA user code cannot use Print for a method name, it's reserved).
So Debug statements are basically special kinds of keywords. IntelliSense / parameter quick-info is shown for argument list syntax elements, but syntactically, the "arguments" of a Debug.Print are an output list, exactly like the Print statement does.
Note that the VBE automatically turns a ? token into a Print statement:
Debug.? --> Debug.Print
There's quite a bit of historical baggage with Print: the keyword/command (and its ? shorthand) was used in old BASIC dialects to output things to a screen... or an actual [dot matrix!] printer.
So the short answer is, Debug statements are made with keywords, not member calls - and that's why IntelliSense isn't of any use with them, since there aren't any arguments.
The Rubberduck project has a fun story with these statements... because it isn't really possible to parse a typical Debug.Print statement any differently than any other implicit callStmt (i.e. it looks and parses like any other procedure call), we had to give the statement its own dedicated parser rule, and "declare" a fake DebugClass module and make Print a "method" of that "class" in order to be able to track uses like we do with other early-bound identifier references:
But there really isn't such a thing: statements with an output list are baked into the language at the parser & compiler level, whereas literally every other member call you ever made in VBA was a member of some module - hit F2 and browse the members of the VBA standard library: you'll find CLng type conversion, Now and DateAdd date/time functions, MsgBox, DoEvents, and so many others - all belong to some module. But Debug statements are closer to a Stop or Resume keyword, handled at a lower level.
Further proof that there's more than meets the eyes - other than the simple fact that default syntax highlighting in the VBE will highlight both Debug and Print in bright keyword-blue, if you compile a COM-visible class written in C#:
[ComVisible(true)]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
[Guid("6F25002E-2C9F-4D77-8CCB-A9C0E4FB2EF1")]
public interface ITestClass
{
[DispId(1)]
void Print(string value);
[DispId(2)]
void DoSomething();
}
[ComVisible(true)]
[ComDefaultInterface(typeof(ITestClass))]
[ClassInterface(ClassInterfaceType.None)]
[Guid("6F25002E-2C9F-4D77-9624-6CA79D4F088A")]
[ProgId("PrintTest.Class1")]
[EditorBrowsable(EditorBrowsableState.Always)]
public class Class1 : ITestClass
{
public void Print(string value)
{
/* no-op */
}
public void DoSomething()
{
/* no-op */
}
}
..and then invoke it from VBA code...
The DoSomething method can be invoked, but the Print method will throw error 438 - just like it would if you tried to qualify it with anything other than Debug. So how come Print works in an Access report's code-behind then?
The interface isn't documented so this is pure speculation, but there's an IVBPrint interface that looks very much like something VBA would be looking for:
[
odl,
uuid(000204F0-0000-0000-C000-000000000046),
nonextensible
]
interface IVBPrint : IUnknown {
HRESULT _stdcall WriteText([in] BSTR strText);
[propput]
HRESULT _stdcall Column([in] long retVal);
[propget]
HRESULT _stdcall Column([out, retval] long* retVal);
};
If that's the case, then error 438 is just VBA's way to say "IVBPrint implementation not found"
I wish to ask a conceptual question. My code is to print an array of float values of 5 decimal places onto the console. Why must it be String instead of Float? Ans[y] is an array of type float.
println(String(format: "%.5f", Ans[y]))
Instead of Float
println(Float(format: "%.5f", Ans[y]))
Float gives an error of extra argument 'format' in call
You can use map() to format your Float array as string array. Btw you should give it a name starting with a lowercase letter. Try doing as follow:
let floatArray:[Float] = [1.23456,3.21098,2.78901]
let formattedArray = floatArray.map{String(format: "%.5f", $0)}
println(formattedArray) // "[1.23456, 3.21098, 2.78901]"
It's just a matter of understanding what your words mean. String is an object type (a struct). Float is an object type (a struct). The syntax Thing(...) calls a Thing initializer - it creates a new object of type Thing and calls an initializer method init(...). That's what you're doing when you say String(...) and Float(...).
Well, there is a String init(format:) initializer (it actually comes from Foundation NSString, to which String is bridged), but there is no Float init(format:) initializer - the Float struct doesn't declare any such thing. So in the second code you're calling a non-existent method.
You can use NSLog instead of println. NSLog is still in the foundation class and has the flexibility of specifying the exact format you need.
i need to know how to use a variable in parameters
PROCESS is initalized as
string PROCESS in the class parameters.
Process::GetProcessesByName("")
which gives me an error when i replace the string with a variable
Process::GetProcessesByName(PROCESS)
The error i get back is:
No instance of overloaded function "System::Diagnostics::Process::GetProcessByName" Matches the argument list argument types are (std::string)
I think GetProcessesByName may take a parameter as LPSTR or char const *, but not a std::string,
try use
Process::GetProcessesByName(PROCESS.c_str());
or if your PROCESS is defined as std::string PROCESS;,
String^ process_name = gcnew String(PROCESS.c_str());
Process::GetProcessesByName(process_name);
I am currently trying to create a natvis XML file for a large Project at work.
We have a Pointer to a type, which the Debugger knows nothing of (Information hiding with a typedef, it was a stupid idea by the author, but can't be changed at the Moment...).
The original struct is similar to this one (the Debugger knows nothing of These types, he only sees the pointer):
struct INNER_1_t
{
int* pointerToArray;
int n;
}
struct INNER_2_t
{
int v_1;
int v_2;
}
struct OUTER_t
{
/* a lot of other, primitive members ... */
int lface;
int *edges; //Array with num_edges members
int num_edges;
INNER_1_t *ptr1; //Array with n1 members
int n1;
INNER_2_t *ptr2; //Array with n2 items
int n2;
}
My Goal is to make the members of this struct visible via a natvis XML file.
For the normal members, this is easy, with Items and pointer arithmetic.
Example:
<Item Name="lface">*((int*)(((char*)this)+92))</Item>
I also know how to define Arrays of known types:
<Synthetic Name="edge">
<DisplayString>Edges({*((int*)(((char*)this)+80))})</DisplayString>
<Expand>
<ArrayItems>
<Size>*((int*)(((char*)this)+80))</Size>
<ValuePointer>*((double**)(((char*)this)+76))</ValuePointer>
</ArrayItems>
</Expand>
</Synthetic>
Is there any way to define an Array of an (for the Debugger) UNKNOWN type?
Or can i somehow declare the type inside the XML file?
I'm currently experimenting with something similar. If you have access to OUTER_t but not the inner ones, I think one strategy involves declaring Types for INNER_1_t and INNER_2_t, with Items corresponding to the locations you expect the private/invisible fields to be. You need to know the exact offsets and types, and watch out for compiler alignment options. So you won't be creating a whole class from scratch in natvis, but rather faking the display of the opaque types. If the array entries are void pointers, you might be out of luck, but with a typedef you should be able to safely cast to whatever the real type is. You can only customize non-primitive types (with the exception of HRESULT).
FWIW, I learned at https://stackoverflow.com/a/11545420/611672 that you can turn on natvis diagnostics with a registry key at
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0_Config\Debugger]
"EnableNatvisDiagnostics"=dword:00000001
There's also a syntax guide at http://msdn.microsoft.com/en-us/library/vstudio/jj620914.aspx if that helps.
Good luck.
The code below generates exception:
Unhandled Exception: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: Cannot implicitly convert type 'void' to 'object'
var m = M((dynamic)d); //Exception thrown here
private void M(Int32 n) { Console.WriteLine("M(Int32): " + n); }
I think that null should be assigned to the m variable instead of exception.
Any idea?
Edit
Please note that below generates compile time error
dynamic result = M(1);//compile time error: Cannot implicitly convert type 'void' to 'dynamic'
private void M(Int32 n) { }
Normally questions like this are answered with a specification reference showing that the compiler / run-time is actually doing the right thing. In this case, the relevant section of the spec (7.2.2) is relatively silent. It basically says that the exact details are implementation-specific.
However, I would argue that it's doing the right thing: if you think of dynamic typing as roughly translating to letting the compiler operate in the same way, but using the actual types of expressions as they are at execution time, then it's entirely reasonable to have an execution time error. The normal compiler behaviour when calling a void method is to prohibit using it as the right-hand side of an assignment expression, so why should that change just because the binding is done at execution time?