I have the following line of code in my application:
CString strAppName = AfxGetAppName();
Sometimes it fills strAppName up with garbage characters, and I can't figure out why.
Anyone have any ideas?
TIA.
That is possible if you change m_pszAppName manually.
At the very beginning of application initialization, AfxWinInit calls CWinApp::SetCurrentHandles, which caches the current value of the m_pszAppName pointer as follows:
pModuleState->m_lpszCurrentAppName = m_pszAppName;
That is, the module state struct holds a copy of the m_pszAppName pointer. If you change m_pszAppName in InitInstance as adviced in MSDN, you still have the old pointer value in pModuleState->m_lpszCurrentAppName. The AfxGetAppName() function returns AfxGetModuleState()->m_lpszCurrentAppName.
You could add data breakpoint on m_lpszCurrentAppName and on m_pszAppName. It is initialized in <...>\Microsoft Visual Studio 9.0\VC\atlmfc\src\mfc\appinit.cpp file. You'll see what is going on with that variable and who's trying to change it.
Related
I have a function in which I populate some string variables. problem is I set 6 vars with source and destination path,names and extensions, I set a further two variables and one of the file varaibles changes as well.
lAppendStr.assign(ID_MONGODB_APPEND); // "smallfiles=true\0";
lSearchStr.assign(ID_MONGODB_APPEND); // "smallfiles=true\0";
lSrcPath.assign(ID_MONGOODB_PATH); // "/etc/\0" ;
lSrcName.assign(ID_MONGOODB_NAME); // "mongodb\0";
lSrcExt.assign(ID_MONGOODB_EXT); // ".conf\0";
lDestPath.assign(ID_MONGOODB_PATH); // "/etc/\0";
lDestName.assign(ID_MONGOODB_PATH); // "mongodb\0";
lDestExt.assign(ID_DEFAULT); // "def";
when .def is assigned, lAppendStr is also populated with .def
All vars are strings and initialised with "" the ID definitions are terminated with \0 but only as a clutch at straws operation.
I have tried using the string values instead of the ID, and moving the list around changes the assignment results but the variables are still getting cross contaminated.
This is obviously part of larger code, but I guess in my mind is a memory boundary problem. I also posted an issue regarding a call to construct a class, which feels like a it could be in the same vein.
This is LINUX os developed on a MacBookair, in an eclipse oxygen dev editor environment.
Any guidance would be greatly appreciated.
In the code I maintain I run across:
from win32com.shell import shell, shellcon
# ...
result,nAborted,mapping = shell.SHFileOperation(
(parent,operation,source,target,flags,None,None))
In Python27\Lib\site-packages\win32comext\shell\ (note win32comext) I just have a shell.pyd binary.
What is the return value of shell.SHFileOperation for a deletion (operation=FO_DELETE in the call above) ? Where is the code for the shell.pyd ?
Can I get the list of files actually deleted from this return value or do I have to manually check afterwards ?
EDIT: accepted answer answers Q1 - having a look at the source of pywin32-219\com\win32comext\shell\src\shell.cpp I see that static PyObject *PySHFileOperation() delegates to SHFileOperation which does not seem to return any info on which files failed to be deleted - so I guess answer to Q2 is "no".
ActiveState Python help contains SHFileOperation description:
shell.SHFileOperation
int, int = SHFileOperation(operation)
Copies, moves, renames, or deletes a file system object.
Parameters
operation : SHFILEOPSTRUCT
Defines the operation to perform.
Return Value
The result is a tuple containing int result of the
function itself, and the result of the fAnyOperationsAborted member
after the operation. If Flags contains FOF_WANTMAPPINGHANDLE, returned
tuple will have a 3rd member containing a sequence of 2-tuples with
the old and new file names of renamed files. This will only have any
content if FOF_RENAMEONCOLLISION was specified, and some filename
conflicts actually occurred.
Source code can be downloaded here: http://sourceforge.net/projects/pywin32/files/pywin32/Build%20219/ (pywin32-219.zip)
Just unpack and go to .\pywin32-219\com\win32comext\shell\src\
I am facing issues with memory allocation in Scilab after compiling.
I am compiling on a Red Hat on ppc64 (POWER8). Stack limits are already set to unlimited (ulimit -s unlimited). The ./configure script (with several options I am not showing here) runs successfully, but the make all fails and stops. When it stops, it is stuck at the Scilab command prompt with this message:
./bin/scilab-cli -ns -noatomsautoload -f modules/functions/scripts/buildmacros/buildmacros.sce
stacksize(5000000);
!--error 10001
stacksize: Cannot allocate memory.
%s: Cannot allocate this quantity of memory.
at line 27 of exec file called by :
exec('modules/functions/scripts/buildmacros/buildmacros.sce',-1)
-->
I have investigated a bit, and that error message seems to be called of course at line 00027 in buildmatros.sce, where the function stacksize(5000000) is called.
This function is defined in:
scilab-5.5.1/modules/core/sci_gateway/c/sci_stacksize.c
I found a version of the file at this page: http://doxygen.scilab.org/master_wg/d5/dfb/sci__stacksize_8c_source.html.
The condition that is FALSE and that triggers the message seems to me to show up at line 00295.
Inside that file, you see that error is displayed whenever the stacksize given as input is LARGER than what is returned by the method get_max_memory_for_scilab_stack() from the class:
scilab-5.5.1/modules/core/src/c/stackinfo.c
Again I found a version online at the following page:
http://doxygen.scilab.org/master_wg/dd/dfb/stackinfo_8h.html#afbd65a57df45bed9445a7393a4558395
The Method is declared from line 109.
It seems to invoke a variable called MAXLONG, which is however NEVER explicitly declared! As you see, it is declared several times (line 00019, 00035, 00043, 00050), but all lines are commented! [correction: the lines are NOT commented, it was my false understanding of # being a comment sign, but it's not]
So my guess is: MAXLONG is not declared, so the function does not return a value (or it returns 0) and therefore the error message is triggered because the stacksize given as input is higher than 0 or NULL or N/A.
My questions are then:
Why are all lines commented where MAXLONG is defined?
Where does MAXLONG originate from? Is it something passed from the kernel?
How can I solve the problem?
Thanks!
PS - I tried to uncomment the line in buildmacros, and it compiled and installed without issues. However, when I started scilab-cli, it displayed the same message again.
Edit after further investigation:
After further investigation, I found out that what I thought were the comments are indeed instructions for the compiler... but I kept those errors of mine, so that the answer to my question is understandable.
Here are my new points.
In Scilab I noticed that by giving an input stacksize out of bounds, the same method get_max_memory_for_scilab_stack() is invoked, to get the upper bound. The lower bound I've seen it's defined by default.
-->stacksize(1)
!--error 1504
stacksize: Out of bounds value. Not in [180000,268435454].
Also the stacksize used seems fine:
-->stacksize()
ans =
7999994. 332.
However, when trying to give such value an input inbetween, it fails.
-->stacksize(1)
!--error 1504
stacksize: Out of bounds value. Not in [180000,268435454].
It seems to invoke a variable called MAXLONG
It's not a variable, but a pre-processor macro.
Why are all lines commented where MAXLONG is defined?
You should ask that from the person who commented the lines. They're not commented in scilab-5.5.1 that's online.
Where does MAXLONG originate from? Is it something passed from the kernel?
It's defined in the file scilab-5.5.1/modules/core/src/c/stackinfo.c. It's defined to the same value as LONG_MAX which is defined by the standard c library (<limits.h> header). If the macro is not supplied by the standard library, then it's defined to some other, platform specific value.
How can I solve the problem?
If your problem originates from the lack of definition for MAXLONG, then you must define it. One way going about it is to uncomment the lines that define it. Or re-download the original sources since yours don't appear to match with the official ones.
I am using QSettings to try and figure out if an INI is valid.(using status() to check) I made a purposefully invalid INI file and loaded it in. The first time the code is called, it returns invalid, but every time after that, it returns valid. Is this a bug in my code?
It's a Qt bug caused by some global state. Note that the difference in results happens whether or not you call delete on your QSettings object, which you should. Here's a brief summary of what happens on the first run:
The result code is set to NoError.
A global cache is checked to see if your file is present
Your file isn't present the first time, so it's parsed on qsettings.cpp line 1530 (Qt-4.6.2)
Parsing results in an error and the result code is set (see qsettings.cpp line 1552).
The error result code is returned.
And the second run is different:
The result code is set to NoError.
A global cache is checked, your file is present.
The file size and timestamp are checked to see if the file has changed (see qsettings.cpp line 1424).
The result code is returned, which happens to be NoError -- the file was assumed to have been parsed correctly.
Checked your code, you need to delete the file object before returning.
Apart from that, your code uses the QSettings::QSettings(fileName, format) c'tor to open an ini-file. That call ends in the function QConfFile::fromName (implemented in qsettings.cpp). As I read it (there are a few macros and such that I decided not to follow), the file is not re-opened if the file already is open (i.e. you have not deleted the object since the last time). Thus the status will be ok the second time around.
One of my functions returns a 'msg' object... which is merely a string.
I got into 2 for loops in the function.
msg=''
for e in example:
msg+= "some crap"
msg+= "some crap1"
for sl in somelist
msg+= v.somevalue
msg+="-------------"
return httpresponse(msg)
There's an example of the code.
'somelist' contains two values... when the 'msg' returns it only returns the second of the two values! I'm rather confused.
Your code uses sl as the loop variable, then pulls values from v. I'm not sure how they relate. If the final message includes a number of copies of the last value, then probably you forgot to relate sl and v somehow. If it includes only a single copy of the last value, then perhaps the line of code appending to msg is actually outside the loop. This would mean nothing is appended as the loop progresses, then once it exits, the last value is appended.
If your code is exactly like that, it should work just like you want it to. However, as this clearly isn't the actual code, I'd guess you have msg = ... somewhere, when you should have msg += ... At least that's the most likely reason for the behaviour you're seeing.
If you have trouble finding where it goes wrong, put in there some "print msg" statements and test it by running your Django project in development server. You'll see where it goes wrong.