I am working with imageDraw and getting an odd error. If I just plugin values and don't try to use the ones I am retrieving from elsewhere, it works, but I have to draw the values for the margins and line height from other places and calculate stuff.
x = 50;
y = 800;
newImg = imageNew("", x, y);
imageSetAntialiasing(newImg, true);
setup['size'] = lineHeight*dpi;
setup['font'] = "Arial";
imageDrawText(newImg,img.text,topMargin,leftMargin,setup);
When I put each element in imageDrawText on a separate line, the error points to the attribute collection (setup). I did try this
setup['size'] = "#lineHeight*dpi#";
but it didn't work either.
The full error message at the top of the debug:
Error Occurred While Processing Request
Error casting an object of
type java.lang.Double cannot be cast to java.lang.String to an
incompatible type. This usually indicates a programming error in Java,
although it could also mean you have tried to use a foreign object in
a different way than it was designed. java.lang.Double cannot be
cast to java.lang.String
That's a bug in older ColdFusion versions (before ColdFusion 2016), because the size attribute is explicitly casted: (String)size. And even if you pass the value as String, your value may not contain decimal places, because ColdFusion attempts to parse the value as Integer: Integer.parseInt((String)size)
// works
setup['size'] = "12";
// works, because literal numbers are casted to String
setup['size'] = 12;
// DOES NOT work, because any math calculation results into a Double
setup['size'] = 12 * 1;
// DOES NOT work, because this is a Double
setup['size'] = 12.1;
Your solution using setup['size'] = toString(int(...)); is the correct workaround for this bug. int() to make sure you end up without decimal places (preventing NumberFormatException) and toString() to make sure you are passing a String (preventing ClassCastException).
(This post is more like a remark, but too long for a comment. Feel free to accept your own answer.)
There is something about asking for help that opens up channels for me. Found a solution. The issue was indeed the setup.size part of the attribute collection. Here is what worked:
setup['size'] = toString(int(lineHeight*dpi));
Don't know why it wants that to be a string specifically. Seems kind of dumb because we are using it as a number.
Related
TLDR: Could someone explain how to correctly use the SymGetTypeInfo.
My goal is to get the type information for local variables (wherever Rip/Eip happens to be).
According to the documentation, I need to call the SymSetContext with the IMAGEHLP_STACK_FRAME structure filled with appropriate values. I got this part working as when I call SymEnumSymbols (setting the BaseOfDll parameter to 0 as the doc says to do when setting context), I do in fact only get the local variables.
HOWEVER:
When inside the enumerate symbols callback, I try to call SymGetTypeInfo, something like this:
static BOOL s_enum_symbols_callback(
PSYMBOL_INFO pSymInfo,
ULONG SymbolSize,
PVOID UserContext) {
// ...
HANDLE hProcess = /*Defined elsewhere*/;
wchar_t *buffer = (wchar_t *)allocate_symname_memory();
SymGetTypeInfo(hProcess, pSymInfo->ModBase, pSymInfo->TypeIndex, TI_GET_SYMNAME, &buffer);
}
SymGetTypeInfo fails with error 1 ("Incorrect function").
Ok so now I am troubleshooting to figure out why this might happen. My first theory is that this may have something to do with setting the context, so I remove the SymSetContext and enumerate again. This time (I obviously get all the symbols), and I get the same problem except for a few types, notably: I am able to get the type of __scrt_current_native_startup_state (which is __scrt_native_startup_state).
Ok so maybe... the problem is that I am calling SymGetTypeInfo inside a Sym* callback function?? (doubt it though). Anyway, I put the theory to the test, and enumerate just the symbols which I have defined globally:
wchar_t global_variable = 12;
int global_variable0 = 12;
float global_variable1 = 12.0f;
int global_variable2 = 12;
Once again, not setting the context, I enumerate the symbols and note the TypeIndex value for each so that once outside of the enumerate symbols function, I call SymGetTypeInfo like this:
SymGetTypeInfo(hProcess, process_pdb_base, type_index, TI_GET_SYMNAME, &buffer);
(process_pdb_base is returned from SymModuleLoad64).
And I get the SAME problem.
Maybe I am completely misunderstanding what the TypeIndex really is? (although it is consistent for different variables with the same type), or maybe it's only for user-defined types??
So yeah I am lost and tired, please help internet.
Alright guys, I think I figured it out and it's all thanks to this marvelous article written in 2004, by Oleg Starodumov!
And one of my theories wasn't completely wrong - I did indeed misunderstand what the Debug Help (well actually, the entire Win32 API!) library refers to, when using the word "type". As the article wonderfully puts it: "The type of an object defines the set of properties supported by the object, and the set of possible relationships between the object and other objects."
So really, the SymGetTypeInfo functions, is just used to query information about any symbol. Now there are indeed different categories of symbols, which are encapsulated by the SymTagEnum enumerator type which is defined in DbgHelp.h IF you have _NO_CVCONST_H defined with #define (NOTE: You use this if you don't have access to cvconst.h which was my case).
Because this article is so great and I don't want to spoil it for anyone, I will quickly resume what I needed to do to fix my issue, instead of trying to explain querying the C/C++ "type" information (not Win32 "type") of a variable.
The first thing I needed to do, was get the tag of the symbol which represented the C/C++ "type" of the local variable symbol (which is indeed stored in TypeIndex). Next, I needed the code to act accordingly for each different possible tag. In my case, because this was what was called a BaseType, I needed to query what BaseType the type symbol was. With this:
SymGetTypeInfo(hProcess, pSymInfo->ModBase, pSymInfo->TypeIndex, TI_GET_BASETYPE, &type);
Now, each base type has a corresponding enum constant associated with it. The enum looks like this:
enum BasicType
{
btNoType = 0,
btVoid = 1,
btChar = 2,
btWChar = 3,
btInt = 6,
btUInt = 7,
btFloat = 8,
btBCD = 9,
btBool = 10,
btLong = 13,
btULong = 14,
btCurrency = 25,
btDate = 26,
btVariant = 27,
btComplex = 28,
btBit = 29,
btBSTR = 30,
btHresult = 31
};
And lo and behold, the base type did in fact correspond with the types of my local variables!
NOTE
I couldn't find this enum in my system (most likely because I didn't have the Debugger Interface Access SDK), so to get it, I simply copied the TypeInfoStructs.h file located in another link provided by Oleg Starodumov.
We have a business need to collect specific bindings in every JSF page. and we do that inside overridden ViewHandlerWrapper class
I use the below code inside renderView method to get the whole expression value property for every RichInputText and it's work fine for me
ValueExpression valExp = Inputcomponent.getValueExpression("value");
String ExpressionString = valExp.getExpressionString();
output was: #{binding.EmployeeId.inputValue}
When I do the same against RichButtin I got null value as following:
ValueExpression valExp = Btncomponent.getValueExpression("actionlistener");
String ExpressionString = valExp.getExpressionString();
What is the wrong in my last peace of code?
Obtaining a ValueExpression form a RichInputText works because, as the name suggests, it evaluates to a value, which may or may not be an EL expression, let alone a method.
On the other hand, a RichButton does not really have to evaluate to something; rather, it aims to invoke behavior (i.e. a method), from which you would want a MethodExpression - though in this case, the closest we get to it is a MethodBinding.
Luckily, UIXCommand, a superclass of RichButton, provides two methods from which you can obtain your action listeners:
public final MethodBinding getActionListener()
From the MethodBinding returned, you can invoke getExpressionString() so you can get what you wanted - such as some actionListener EL string like #{binding.bean.actionListenerMethod}.
public final ActionListener[] getActionListeners()
Might be worth mentioning, though there is not much merit for this in your use case. It simply returns the listeners on which you can manually process the events.
I am trying to assign some simple text to my CString variables. The CStrings are member variables for Edit Controls in MFC.
I am assigning the following values with code as follows:
BOOL CImageDisplay::OnInitDialog()
{
... //Has nothing to do with the email variables
m_mailTo = "example#domain.com";
m_mailSubject = "Admin Options Test Email Subject";
m_mailBody = "This is a test email sent from Admin Options.";
return true;
}
The values show correctly in my GUI. My problem is that when I debug my program, my values are immediately incorrect. I have a < Bad Ptr> for my first value. My second variable has the value I assigned to my first varaible, as so forth:
m_mailTo = Bad Ptr
m_mailSubject = "example#domain.com"
m_mailBody = Admin Options Test Email Subject"
I do not understand why my variables hold these values when I clearly set them. Thanks for any help to this confusing problem!
I can add more code if necessary, I just didn't want to flood the page if it was not needed.
As Igor Tandetnik stated, my PDB file (the debugging information) was stale. Although I was receiving invalid debugging values, they were actually correct.
This was fixed by going to build -> Rebuild Solution.
Currently, I'm working on compiling old .cpp classes under C++ Builder XE. Apart from many troubles, there is one which I have completely no idea how to solve.
My code:
String txt = "<Not so long sql query>";
int licz = some_function(txt, dzeFDS); //1
//assigning licz to somewhere
txt = "<much longer query>";
licz = some_function(txt, budFDS); //2
Problem is that during second call of some_function program is stopped and i have this alert:
First chance exception at $75A1C42D. Exception class EDatabaseError with message 'budFDS: Type mismatch for field 'Function', expecting: String actual: WideString'. Process Call.exe (1896)
It's strange form be, bacause first call of some_function works fine, but this second one (with arguments with the same type) doesn't.
some_function code:
int __fastcall some_function(String txt, TIBDataSet *firDS)
{
firDS->Close();
firDS->SelectSQL->Text = txt;
firDS->Open(); //during debugging, exception occurs in this line
int count = 0;
while(!firDS->Eof)
{ count++;
firDS->Next();
}
return count;
}
Any ideas what why it happens?
Thanks in advance
There is much pain in your future.
Anyway, the problem you're having is with the database connection. There's a field in your database called "Function" that holds a string. This field came across as a String with the ancient database driver that this program originally used. Your shiny, new database driver is telling VCL to expect such things as Unicode, and VCL doesn't like to shove such things into plain Strings, so it expects you to have a WideString ready in which to shove it.
Fortunately, there are ways of beating VCL into submission. What you want to do, since you surely don't want to rewrite half the application by changing TIBDataSet, is to tell the connection not to bother with Unicode. In order to do this, you have to set up the TSQLConnection object with UseUnicode=false, which I hope (I have no way of testing VCL code anymore) should look something like this:
connection->Params->Add("UseUnicode=false");
Where connection is the TSQLConnection object. I think you have to do this before connecting to the database.
If that doesn't work, see if you can configure the database driver to not use Unicode.
Problem solved - this one field Function has other type in C++ Builder design view - it was TStringField, and rest fields has TIBStringField...
I am learning how to use the OpenISO8583.Net code. I have derived a new ISO8583 class from the original one. One of the differences in my new class is that the Message Type field is going to be [Numeric, BCD]; so I wrote this as part of the class contructor (I do have a custom DefaultTemplate declared as part of the class):
DefaultTemplate.MsgTypeFormatter = Formatters.Bcd;
I created a new message with a message type of 0100 (MsgType._0100_AUTH_REQ). Without assigning any other bits.
FDISO8583 fdISO8583 = new FDISO8583();
fdISO8583.MessageType = FDISO8583.MsgType._0100_AUTH_REQ;
byte[] testMsg = fdISO8583.ToMsg();
My ending result byte array is: 01-00-00-00-00-00-00-00-00-00 which I think is correct. First 2 bytes for the message type with the BCD value and the bitmap is all zeroes.
Now the problem is when I test unpacking it. Using:
fdISO8583 = new FDISO8583();
int pos = fdISO8583.Unpack(testMsg, 0);
The resulting message type gets a value of zero.
I need help understanding if this is a problem on the way I defined the class or a bug in the ISO8583 code.
You have indeed found a bug. I logged it as Issue 13 and have fixed it. I have release version 0.5.2 on nuget and uploaded the bin file to the googlecode project.