I've been trying to access an image resource named "IndexPointer.jpg" in an embedded RESX file called "Images.resx". GetManifestResourceNames() returns a single value - SCtor.Images.resources".
Assembly::GetExecutingAssembly()->GetManifestResourceStream("SCtor.Images.resources.IndexPointer.jpg")
only returns a nullptr. Obviously, I've got the manifest name wrong. What would be the correct one ?
Open the assembly with Reflector to find out the correct resource name.
Well, I finally figured it out. Strangely, I recall coming across (and trying out) the working solution and disregarding it. In any case, I instantiated a ResourceManager object with my assembly's resource and used its GetObject method to extract the embedded image.
ResourceManager^ resources = gcnew ResourceManager("<rootNamespace>.<resourceName>", Assembly::GetExecutingAssembly());
Bitmap^ Image1 = gcnew Bitmap(dynamic_cast<Image^>(resources->GetObject("<nameOfTheImageResourceWithoutItsExtension>")));
Related
There is a task to call DLL file and get output to the promptassignment variable in automation anywhere. That DLL returns the object (with student name and age). Is there any way to extract that students name and age from Promptassignmet variable without calling another DLL? Thnak you in advance.
Not in the way you would want it to work, no.
Keep in mind that AA is by no means Object oriented. Hence, the parsing of the returned object needs to be done either in the dll itself (if you have access to its source code) or by AA's Before-After String operation.
Note that the latter is only viable when the returned Student object is not hashed, e.g. "Obj#12f837g", but has a ToString() format, e.g. "{student:{name:Foo, age:12}}".
In the former approach, instead of returning the Student object, you could return student.name + ";" + student.age; for example.
If neither of the 2 options listed above are viable for you, you can try creating a metabot via the Metabot Designer in the AAE Client. You can attach the dll and check if you can call its methods individually. The goal would be to find a Getter method for both 'name' and 'age'.
If all else fails, yes, you'll need to either run another dll which would serve your purpose, or create the dll yourself (this sounds like a fairly easy dll, but I could be wrong of course).
Hopefully one of the above will help you or at least guide you on finding your own solution.
I know in vb.net you can use System.Reflection.MethodInfo.GetCurrentMethod.ToString to get the name of the current method you are in. However, is there a way to use System.Reflection... to get the name of the current file you are in?
So if you had a file in the project named blah.vb I would want System.Reflection... to return blah.vb
Is this possible?
You can use System.Reflection.Assembly to find the file name of the current assembly. There are several applicable methods to choose from:
GetEntryAssembly - Returns the assembly that started the process (the executable)
GetCallingAssembly - Returns the assembly that called the current method
GetExecutingAssembly - Returns the assembly in which the current method resides
I suspect that what you want is GetExecutingAssembly. All of those methods return an Assembly object through which you can get the file path, like this:
Dim myFilePath As String = System.Reflection.Assembly.GetExecutingAssembly().Location
For what it's worth, if you need get the file name of the executable, but it's not a .NET assembly (because you're in a .NET library invoked via COM), then the above method won't work. For that, the best option would be to grab the first argument from the command line, like this:
Dim myComExeFile As String = Environment.GetCommandLineArgs()(0)
i've assumed that dumping a .bc file from a module was a trivial operation, but now,
first time i have to actually do it from code, for the life of me i
can't find one missing step in the process:
static void WriteModule ( const Module * M, BitstreamWriter & Stream )
http://llvm.org/docs/doxygen/html/BitcodeWriter_8cpp.html#a828cec7a8fed9d232556420efef7ae89
to write that module, first i need a BistreamWriter
BitstreamWriter::BitstreamWriter (SmallVectorImpl< char > &O)
http://llvm.org/docs/doxygen/html/classllvm_1_1BitstreamWriter.html
and for a BitstreamWriter i need a SmallVectorImpl. But, what next?
Should i write the content of the SmallVectorImpl byte by byte on a
file handler myself? is there a llvm api for this? do i need something
else?
The WriteModule function is static within lib/Bitcode/Writer/BitcodeWriter.cpp, which means it's not there for outside consumption (you can't even access it).
The same file has another function, however, called WriteBitcodeToFile, with this interface:
/// WriteBitcodeToFile - Write the specified module to the specified output
/// stream.
void llvm::WriteBitcodeToFile(const Module *M, raw_ostream &Out);
I can't imagine a more convenient interface. The header file declaring it is ./include/llvm/Bitcode/ReaderWriter.h, by the way.
I use following code :
std::error_code EC;
llvm::raw_fd_ostream OS("module", EC, llvm::sys::fs::F_None);
WriteBitcodeToFile(pBiFModule, OS);
OS.flush();
and then disassemble using llvm-dis.
When using the Ext.data.Store 'mapping' config property, of 'x.y', and the mapped model does not contain an 'x' property, the store throws an exception, which, prevents the store data from rendering into the grid view on data store load.
If the store source is out of your control, is it possible to avoid/catch the exception when the root of the mapping path does not exist. I've tried using a 'convert' function for the target property of the data store. The mapping path into the JSON document is only determined from the run context [e.g. this.mappingPath]. Dynamically generating the convert function (to catch the exception) seems to slow down the page a bit.
Is there a solution to null results along the model's mapping path within the ExtJS API, or is catching the exception from within the convert function the way to go? Or possibly another solution...
I ended up just using a convert function with a call to a 'followPath' type function anywhere that this was the case. Follow path breaks up the mapping component into it's parts (split on '.') and iterates through the list readjusting the context to context = context[part] along the way. so the call is followPath(item.data,path). This performs well, and gets the job done.
I am writing an Eclipse plug-in that uses JDT AST's ASTParser to parse a method. I am looking within that method for the creation of a particular type of object.
When I find a ClassInstanceCreation, I call getType() on it to see what type is being instantiated. I want to be sure that the fully-resolved type being dealt with there is the one I think it is, so I tell the resultant Type object to resolveBinding(). I get null back even though there are no compilation errors and even though I called setResolveBindings(true) on my ASTParser. I gave my ASTParser (via setSource()) the ICompilationUnit that contains my method, so the parser has access to the entire workspace context.
final IMethod method = ...;
final ASTParser parser = ASTParser.newParser(AST.JLS3);
parser.setResolveBindings(true);
parser.setSource(method.getCompilationUnit());
parser.setSourceRange(method.getSourceRange().getOffset(), method.getSourceRange().getLength());
parser.setKind(ASTParser.K_CLASS_BODY_DECLARATIONS);
final TypeDeclaration astRoot = (TypeDeclaration) parser.createAST(null);
final ClassInstanceCreation classInstanceCreation = walkAstAndFindMyExpression(astRoot);
final Type instantiatedType = classInstanceCreation.getType();
System.out.println("BINDING: " + instantiatedType.resolveBinding());
Why does resolveBinding() return null? How can I get the binding information?
Tucked away at the bottom of the overview of ASTParser.setKind(), carefully hidden from people troubleshooting resolveBinding() and setResolveBindings(), is the statement
Binding information is only computed when kind is K_COMPILATION_UNIT.
(from the online Javadoc)
I don't understand offhand why this would be the case, but it does seem to point pretty clearly at what needs to be different!