I am debugging some code that uses the MFC CDC Class for printing documents, and which have issues with the preview-printing for determining the total number of pages.
When comparing return values from CDC::DrawText for certain elements, I notice that when drawing to memory the return value is positive but then when drawing to printer the return value is negative.
The CDC documentations says DrawText return "The height of the text if the function is successful."
What does a negative value mean?
This is caused by the fact that your two CDC's (memory and printer) have been placed in different mapping modes.
For example, when the CDC's underlying device context is in MM_TEXT mode, then positive y is down whereas, in (most) other modes, positive 'y' is up. A quick test on my own system (albeit using a screen-based CDC) has shown that CDC::DrawText() returns a positive value when the DC is in MM_TEXT mode but a negative value for (e.g.) MM_ISOTROPIC or MM_HIMETRIC.
Whether or not you have explicitly changed the mapping mode for either of your CDCs, I don't know! But, even if you haven't, the MFC framework has probably "done something" to the printer device context - either before you've retrieved it or (more likely) in the OnPreparePrinting function.
for example, that is data:
1,1470732420000,0
2,1470732421000,0
3,1470732422000,0
4,1470732423000,86
5,1470732424000,87
6,1470732425000,88
7,1470732426000,84
8,1470732427000,0
9,1470732428000,0
10,1470732429000,0
11,1470732430000,89
12,1470732431000,89
13,1470732432000,87
14,1470732433000,89
15,1470732434000,85
16,1470732435000,89
17,1470732436000,89
18,1470732437000,87
19,1470732438000,86
20,1470732439000,88
21,1470732440000,0
22,1470732441000,0
23,1470732442000,0
24,1470732443000,87
25,1470732444000,85
26,1470732445000,86
27,1470732446000,0
28,1470732447000,0
29,1470732448000,0
30,1470732449000,0
column one is id,column two is timestamp,column three is value,1 sec interval between the timestamp.
i want monitoring the value of event,if i found out value>=85(e.g. id=4), i will starting counting,if the next two consecutive value>=85(e.g. id=5/id=6),then i will put the third value of event to OutputStream.(e.g. id=6,value=88,timestamp=1470732425000)
at the same time i clear the counting and wait value lower than 85(e.g. id=7,value=84), then i will monitoring again,when i found out value>=85(e.g. id=11,value=89) i will starting counting,if the next two consecutive value>=85(e.g. id=12/id=13),then i will put the third value of event to OutputStream.(e.g. id=13,value=87,timestamp=1470732432000)...
all this is i wanna do,before i post this ask, i've got an answer in this post,i've tried this code:
from every a1=InputStream[value>=85], a2=InputStream[value>=85]+, a3=InputStream[value<85]
select a2[1].id, a2[1].value
having (not (a2[1] is null))
insert into OutPutStream;
and it works,but i found out it will insert the value into OutputStream after the value<=85,and what i want is if i got three consecutive value>=85 then i insert into the value immediately.(i don't want to wait if the next value>=85 all the times)
in fact, i just wanna record value of third seconds in three consecutive seconds value(>=85) .
i'm using wso2das-3.1.0-SNAPSHOT.
Though DAS (Siddhi) supports sequence/pattern processing, for your requirement you might need to write a custom extension. I have written a sample window processor extension to cater your requirement (source code). Download and place siddhi-extension-condition-window-1.0.jar in <das_home>/repository/components/lib/ directory and restart the server. Refer to the test case to get an idea of the usage of the extension.
Could anyone tell me how to interest the results from kcachegrind.
I had two versions of my code (v1, v2) both compiled in debug mode. I ran them through valgrind with options:
valgrind --tool=callgrind -v ....
The output files thus generated are opened in kcachegrind. Now I already found the version v2 of the code runs more faster than first version, v1 as it meant to be. But how do i inperet a result from kcachegrind's call graph.
In kcachegrind All Callers tab, I have the following columns: Incl. , Distance, Called, Caller.
IIUC, Called and caller are the no of times the 'caller' was called in the program. But I dont know about others.
Another thing is when selecting a particular function and then
the 'callers' tab it shows some more information. Ir, Ir per call, count, caller
and in the types tab: `EventType, Incl. Self, short, Formula.
I dont have any idea here.
So far I had read these questions:
KCachegrind interpretation confusion
Confused about profiling result
I use QCacheGrind, so I apologize if something on my screen isn't quite the same as what you see. From what I understand, QCacheGrind is a direct Qt port of KCacheGrind. Additionally, I have the ability to toggle between an Instruction Count and a % of total instructions. For consistency I will refer to the Instruction Count view on any column that can be toggled in this way.
The "All Callers" tab columns should represent the following:
Incl.: The number of instructions that this function generated as a whole broken down by each caller. Because callers are a hierarchy (hence the distance column) there may be several that have the same value if your call stack is deep.
Distance: How many function calls separated is the selected line from the function that is selected in the Flat Profile panel.
Called: The number of time the Caller called the a function that ultimately led to the execution of the selected function).
Caller: The function that directly called or called another caller of your selected function (as determined by Distance).
The Callers tab is more straightforward. It shows the functions that have a distance of 1 from your selected function. In other words, these are the functions that directly invoke your selected function.
Ir: The number of instructions executed in total by the selected function after being called by this caller.
Ir per call: The number of instructions executed per call.
Count: The number of times the selected function was called by the caller.
Caller: The function that directly called the selected function.
For Events, see this page for the handbook. I suspect that if you didn't define your own types all you should see is "Instruction Fetch" and possibly "Cycle Estimation." The quick breakdown on these columns is as follows:
Incl.: Again the total instructions performed by this function and all functions it calls beneath it.
Self: The instructions performed exclusively by this function. This counter only tracks instructions used by this function, not any instruction used by functions that are called by this function.
Short and Formula: These columns are used when defining a custom Event Type. Yours should either be blank or very short (like CEst = Ir) unless you end up defining your own Types.
How to determine winapi EnumDisplaySettings failure? According to MSDN
If the function fails, the return value is zero.
also
Graphics mode indexes start at zero. To obtain information for all of
a display device's graphics modes, make a series of calls to
EnumDisplaySettings, as follows: Set iModeNum to zero for the first
call, and increment iModeNum by one for each subsequent call. Continue
calling the function until the return value is zero.
How to determine if returned zero is a failure sign or mode doesnt exist (iModeNum value too big)?
There's nothing told about GetLastError. It seems like this winapi doesnt set last error on failure.
This is typical for GDI api calls, they don't set the GetLastError error code. All you've got is the "it didn't work" return value.
Do note that you must start with iModeNum at 0. If that returns FALSE then you can safely assume there's something drastically wrong with the device name argument. Keep incrementing iModeNum until you get FALSE.
I am using the IBM cplex optimizer to solve an optimization problem and I don't want all terminal prints that the optimizer does. Is there a member that turns this off in the IloCplex or IloModel class? These are the prints about cuts and iterations. Prints to the terminal are expensive and my problem will eventually be on the order of millions of variables and I don't want to waste time with these superfluous outputs. Thanks.
Using cplex/concert, you can completely turn off cplex's logging to the console with
cpx.setOut(env.getNullStream())
Where cpx is an IloCplex object. You can also use the setOut function to redirect logs to a file.
There are several cplex parameters to control what gets logged, for example MIPInterval will set the number of MIP nodes searched between lines. Turning MIPDisplay to 0 will turn off the display of cuts except when new solutions are found, while MIPDisplay of 5 will show detailed information about every lp-subproblem.
Logging-related parameters include MIPInterval MIPDisplay SimDisplay BarDisplay NetDisplay
You set parameters with the setParam function.
cpx.setParam(IloCplex::MIPInterval, 1000)