On writing to the display with:
::TextOutW( pDC->m_hDC, x, y, &Out, 1 );
It only shows on the screen after every 15 calls (15 characters).
For debugging purposes only, I would like to see the new character on the display after each call. I have tried ::flushall() and a few other things but no change.
TIA
GDI function calls are accumulated and called in batches for performance reasons.
You can call GdiFlush after the TextOut call to perform the drawing immediately. Alternatively, call GdiSetBatchLimit(1) before outputting the text to disable batching completely.
::flushall() is for iostreams, so it won't affect Windows screen output at all. I've never tried it, but based on the docs, I believe GDIFlush() might be what you want. You should also be able to use GDISetBatchLimit(1); to force each call to run immediately upon being called.
Related
I have a selenium script that automates signing up on a website. During the process, I have driver.implicity_wait(60) BUT there is a segment of code where I have a try/except statement where it tries to click something but if it can't be found, it continues. The issue is that if the element isn't there to be clicked, it waits 60 seconds before doing the except part of code. Is there anyway I can have it not wait the 60 seconds before doing the except part? Here is my code:
if PROXYSTATUS==False:
driver.find_element_by_css_selector("img[title='中国大陆']").click()
else:
try:
driver.find_element_by_css_selector("img[title='中国大陆']").click()
except:
pass
In other words if a proxy is used, a pop up will occasionally display, but sometimes it won't. That's why I need the try/except.
You can use set_page_load_timeout to change the default timeout to a lower value that suits you.
You will still need to wait for some amount of time, otherwise you might simply never click on the element you are looking for, because your script will be faster than the page load.
In the try block u can lower the timeout say 10 by using driver.implicity_wait(10) or even to 0. Place this before the find element statement in the try block. Add a finally block and set this back to 60 driver.implicity_wait(60).
I am using container engine, and my pods are hosted there.
I am trying to fetch logs, using log api :
http://localhost:8000/api/v1/namespaces/app-test/pods/designer-0/log?tailLines=100&sinceTime=2017-09-17T10:47:58Z
if i used both the query params separately, it works and show the proper result, but if i am using it simultaneously only the top 100 logs are returning, the sinceTime param is get ignored.
my scenario is, i need a log from a specific time, in a chunk like, 100 lines, 100 lines.. like this.
I am not sure, whether it is a bug, or it is not implemented.
I found this from the api reference manual
https://kubernetes.io/docs/api-reference/v1.6/
tailLines - If set, the number of lines from the end of the logs to
show. If not specified, logs are shown from the creation of the
container or sinceSeconds or sinceTime
So, that means if you specify tailLines, it start from the end. I dont see any option explicitly mentioned other than limitBytes. But you will have to play around with it as it does not guarantee number of lines.
tailLines=X tells the server to start that many lines from the end
sinceTime tells the server to start from the specified time
the options are mutually exclusive
Thanks All,
I have later on recognized that, it is not ignoring the sinceTime, as the TailLines intended functionality is return the lines from the last.
So, if i mentioned the sinceTime= 10 PM yesterday, it will return the records from that time..And if also tailLines, is mentioned, so it will return the recent logs from that chunk.
So, it was working as expected. I need to play with LimitBytes for getting the logs in chunk, from that time, Instead of full logs.
I have a code script in a stack that runs on KeyboardActivated. The codes needs the name of the active control. I can get that by adding on openfield code for each control that generate a KeyboardActivated. But is would be much easier of there was a way for the stack to know which control is active. Is that possible?
You could use a front script. To designate a script a front script, use this syntax
insert the script of control x into front
You can use an openField handler:
global gLastOpenedField
on openField
put the long id of the target into gLastOpenedField
pass openField
end openField
The front script will catch all openField handlers and store the long id of the target into a global variable. Don't forget to pass the openField message on to the next level!
That is what Mark meant. If you trap the "openField" message in a frontScript, and do not pass it, it will be processed, but then discarded. The "pass" command does just that, sends it along the hierarchy.
You can think about this the other way around. If there were no "openField" handler in "front" at all, the message would pass normally through that hierarchy level without being trapped, (this is the normal way) and would then be available to be caught by that field you mentioned.
All handlers work this way. When a message is trapped, it is processed and discarded, unless explicitly passed. The only other way around this trashing is to use the "send" or "dispatch" commands, which can "pass" the message to any object, regardless of its place in the hierarchy.
Did you try using "the target"? I never use front/back scripts and always get things sorted that way. ie:
on KeyboardActivated
put [short] name of the target into MyVar
-- do your stuff
In RPGLE I'm try to get the SFLSCROLL from a DSPF with multiple formats displaying. I used a read of the SFLCTL to get the SFLSCROLL but the screen is waiting for a response.
How can get it to return to the program without the wait?
You can't.
From the manual: 'You use this field-level keyword in the subfile-control record format to return the relative record number of the subfile record that is at the top of the subfile when control is given back to your program.'
You could use WAITRCD() on CRTDSPF to cause a timeout, but you still need to wait for the timeout to expire.
Thank You I did see that solution but here it was a an order issue on the display.
There is a detail screen on the top of the screen then a subfile on the bottom.
(do not ask why the detail was not in the subfile control I think they had planned for multiple details in the header area)
They were doing a write of the sflctl then exfmt for the detail.
That was not giving me the SFLRRN to check new prompt in the subfile.
I changed it to do a write of the detail exfmt of the sflctl read of detail and that got all the data for me to process with them only hitting enter once after the display occurred so I could check the prompt in the subflctl:
C write dtl2
C exfmt sflctl1
C read dtl2
I make several calls to a function that reads data from an input file. Everything works fine in debug mode, but when I try to run the executable from release mode, the line with fopen crashes the program after a few calls. My code is:
From header file:
#define presstankdatabase "presst_database.txt"
In function:
FILE *fidread;
fidread = fopen(presstankdatabase,"r");
if (fidread==NULL) {
printf("Failed to open pressurant tank database: %s\n",presstankdatabase);
return 1;
}
In debugging, I've inserted comment lines just before and just after the line starting with fidread =, and after several calls the program crashes and I get the message "A problem caused the program to stop working correctly. Please close the program." The comment just before the fopen call is displayed, but the comment just after does not. My understanding of fopen is that is should return either a pointer or NULL, but it crashes before it even gets to the check. The only thing I can think of is that somehow I'm having memory problems, but I don't know how that would fit in with fopen crashing. Does anyone know what might be going on? Thanks!
EDIT 1: I increased the size of three variables, and the only places they're used (except in printf() calls), are as shown below.
char *constid = (char*)malloc(sizeof(char)*20);
Used like so:
strcpy(constid,"Propellant");
strcpy(constid,"Propellant tank");
strcpy(constid,"Pressurant tank");
If the variables are sized to 20, as shown above, it crashes. But if they're larger (I've tried 120 and 100), the program runs. The variables aren't used in any other places other than fprintf() or printf() calls.
presstankdatabase should be a pointer to a string containing the filename to open. If fopen() crashes then that pointer is probably invalid (or NULL). Without any more code it is not possible to debug it further. Use the VC debugger to see what's happening...
EDIT:
Another common cause of this is a filename string that suddenly stops being NULL-terminated.
You should add a printf() call to print the filename before opening. It will most probably fail to produce the expected output. If not, then you have a more interesting form of memory corruption that will take some more work to weed out.
EDIT 2:
If the printf() call shows the correct string, then you probably have memory corruption somewhere else in your code that has mangled some internal structure of the C library. A common cause is going beyond the end (or the beginning for that matter) of a static array or a region provided by malloc().