C / C++ / MFC

Quote: Where can I ask questions about TCF? Write an E-Mail to the tcf-dev@eclipse.org mailing list.

I'm getting the same behavior as I suspect you did trying to override the CreateCombo function in a property class derived from CMFCPropertyGridProperty. Did you ever resolve this? AlexJ

There may be multiple users logged in. So you have to enumerate the logon sessions. See this old article: Enumerating Logon Sessions[^]. If the above methods does not work with recent Windows versions, you can use the WTSEnumerateSessions function (Windows)[^] as shown in this SO thread: c++ - How to get the active user when multiple users are logged on in Windows? - Stack Overflow[^].

Lot of unknowns in that very general question. A VPN would normally look like the following Client -> (request) -> VPN -> ('internet') I proxy might look like the following (but other configs possible.) Client -> (request) -> Proxy -> VPN -> ('internet') A 'local' ip address would generally mean something that would not go to the internet at all since it would normally be private. Or at least routed internally. Internet networks will reject a private IP address. But even if that it not what you mean it would suggest that your VPN is still not in play. If you are not sure you can google the following IP public private Also not sure what you wrote (proxy or VPN) but you might validate where that service is actually calling via debugging. One possibility there, depending on what you actually have, is that your proxy is not using the VPN at all.

Your NODE class does not initialise the next and previous members in the constructor. You are initialising them in your DoublyLinkedList class when adding a node. But so valid states depend on that which is dangerous and bad style. You should initialise them in the constructor to ensure that they contain always a defined value. You are allocating your objects on the stack but in DeleteNODE you call delete. Sou you should allocate them on the heap instead: NODE *obj1 = new NODE("Dragu", "Stelian", "1911226284570", "dragu_stelian@yahoo.com"); ptr->AddNODE(obj1); To avoid such wrong allocation, a linked list implementation usually does the allocation (e.g. by not passing an existing object to the add function but the data and let the implementation do the allocation): void DoublyLinkedList::AddNODE(const Persons& person) { // Requires a constructor that accepts a Persons reference NODE *newNode = new NODE(person); // ... } There is also no need to use heap allocation for the box member (which is never getting deleted in your implementation). Just use the structure as member. Instead of finding the reason of your crash I suggest to rethink your design. There are plenty of examples.

Correct settings for a Pi3 are -mfpu=neon-vfpv4 -mfloat-abi=hard -march=armv8-a -mtune=cortex-a53 But I am questioning if you might have to match the compiler settings for the O/S which may even be for an ARM6 given the O/S distribution probably runs on a Pi1. In vino veritas

This is one of those things with frameworks is trying to understand what settings and what dependencies are built in the .lib or .dll file you end up with. You can't answer it easily without going on a fishing expedition. Again I don't use MFC enough to answer this definitively but I will give you want I expect to happen and these days you have the source code to MFC so you can rebuild it any way you want. So lets start the fishing. If it works like everything else on VS the header file will redirect it to the lib directory for MFC, for VS 2017 that will be C:\Program Files\Microsoft Visual Studio 14.0\VC\atlmfc\lib on the 32 bit Windows C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\lib on 64 bit Windows So I go there and I find lots of lib files which I expected. Now if I go up one directory and down to the include directory (I will assume 32 bit windows) C:\Program Files\Microsoft Visual Studio 14.0\VC\atlmfc\include Then pull up the main MFC header file afx.h you will see this, which is how they control which library gets used. #ifndef _AFXDLL #ifdef _AFX_NO_MFC_CONTROLS_IN_DIALOGS #ifdef _DEBUG #pragma comment(lib, "afxnmcdd.lib") #else #pragma comment(lib, "afxnmcd.lib") #endif #pragma comment(linker, "/include:__afxNoMFCControlSupportInDialogs") #pragma comment(linker, "/include:__afxNoMFCControlContainerInDialogs") #endif #ifndef _UNICODE #ifdef _DEBUG #pragma comment(lib, "nafxcwd.lib") #else #pragma comment(lib, "nafxcw.lib") #endif #else #ifdef _DEBUG #pragma comment(lib, "uafxcwd.lib") #else #pragma comment(lib, "uafxcw.lib") #endif #endif #else #ifndef _UNICODE #ifdef _DEBUG #pragma comment(lib, "mfc" _MFC_FILENAME_VER "d.lib") #pragma comment(lib, "mfcs" _MFC_FILENAME_VER "d.lib") #else #pragma comment(lib, "mfc" _MFC_FILENAME_VER ".lib") #pragma comment(lib, "mfcs" _MFC_FILENAME_VER ".lib") #endif #else #ifdef _DEBUG #pragma comment(lib, "mfc" _MFC_FILENAME_VER "ud.lib") #pragma comment(lib, "mfcs" _MFC_FILENAME_VER "ud.lib") #else #pragma comment(lib, "mfc" _MFC_FILENAME_VER "u.lib") #pragma comment(lib, "mfcs" _MFC_FILENAME_VER "u.lib") #endif #endif #endif #ifdef _DLL #if defined(_DEBUG) #pragma comment(lib, "msvcrtd.lib") #else #pragma comment(lib, "msvcrt.lib") #endif #else #if defined(_DEBUG) #pragma comment(lib, "libcmtd.lib") #else #pragma comment(lib, "libcmt.lib") #endif #endif Does that answer you

It looks someone did: sorting - How do I implement quicksort using a batch file? - Stack Overflow[^].

Well At Leon's suggestion I started from scratch with a solution copying my code in Guess what I noticed I had SetThreadName still my code. Obviously with no debugger this would cause problems I am not by trade a Windows programmer but I will say this there seems to be somewhat of a window for (errors going from debug to release) as having MFC140D.DLL in my module list I put MFC140.LIB as input to my linker to get rid of that problems Again thanks to all who have been helping me

Quote: Edit the file properties/pn.props in Visual Studio and fix the paths to WTL and Boost that you've just installed. 'fix hte paths' probably means: 'change the paths to make them correspond to your actual installation of boost and WTL'.

C programs simply cannot use the C++ string class.

You generally do put the initD3D in the WM_CREATE and the cleanD3D in the WM_DESTROY. The problem is you can't really put the render in the WM_PAINT you need to pump the render over and over. So they have done a horrible hack to use the message loop to pump the render. The problem with their hack is they can only have one render window and the render speed is controlled by the message loop. Do you see the sneaky render_frame(); call in the message loop which is the render pump. The correct way to do it is create a thread in WM_CREATE to pump the render call .. good old CreateThread() You can link up WM_WINDOWPOSCHANGED (window size change) and WM_PAINT to the render thread if you want to do things from them to the renderer. So they are basically trying to dodge having to deal with the complexity of having a render thread because it is targetted at beginners. It is horrible as the render complexity and time goes up the message response time goes out the window. MS has a proper threaded samples and there are probably others around Windows Direct3D Multithreaded Rendering Win32 Sample in C++ for Visual Studio 2012[^] NVidia also has do's and dont's ... see under do's ... Master Render Thread DX12 Do's And Don'ts | NVIDIA Developer[^] In vino veritas

Victor Nijegorodov wrote: Just for a test: what will happen if you call mCSVListCtrl.DeleteColumn(0); from anywhere but from this MyClass::OnLvnColumnclickList(...) message handler? It's the same. I think I'll have to go for the dummy left column idea some of you have suggested - maybe I'll use it to number the rows which might be quite nice anyway. Thanks again for all your replies.

I have learned C programming with Turbo C in the late 1980's and can't remember that it supported references. Turbo C was discontinued as stand alone product in 1990 and the C compiler was included with Turbo C++ 1.0. So you probably used that.

Well two problems if we imagine it uninitialized that is it will have some random value. The start value could be any integer value. 1.) Your sum starts at some random value then you do this line sum=sum+workhours; So your answer is some random value + the work hours. Why bother calculating anything the total is just some random number. 2.) You print the answer even if you had zero employees you would print some random value. The compiler will actually throw a warning about this line using uninitialized value due to that The take home message here is variables don't magically start at zero if you want them to start as zero you need to set it to zero. There is one subtlety here that when you are in debug mode it will initialize all variables to zero. That doesn't happen in release mode. So new users when debugging often get caught out because when they look in debug mode sum will start as zero. So the key here is don't set it to zero, compile in release mode ignoring the warning and run your code and watch some random number display. You will have your answer. In vino veritas

In keeping with Davids theme, you could specify an array that's larger than you would ever need, and have the user enter the number of entries first, then setup an input loop based on that. Or setup a loop that runs the same number of times as your array size and have the user enter a value (like -1) that denotes the end of the data at which point you would exit the loop, then process the the data entered prior to the -1 entry. "the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle

See the OP's response here. "One man's wage rise is another man's price increase." - Harold Wilson "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

Quote: I am quite sure the reason I got an assertion was because I did a SetDlgItemText without some how creating a m_hWnd That is very likely. ForNow wrote: On more thing should assert only be used in "debug" Just read the documentation: assert Macro, _assert, _wassert[^] The assert macro is enabled in both the release and debug versions of the C run-time libraries when NDEBUG is not defined. When NDEBUG is defined, the macro is available but does not evaluate its argument and has no effect. When it is enabled, the assert macro calls _wassert for its implementation. Other assertion macros, _ASSERT, _ASSERTE and _ASSERT_EXPR, are also available, but they only evaluate the expressions passed to them when the _DEBUG macro has been defined and when they are in code linked with the debug version of the C run-time libraries. My tip: Use them often (e.g. on top of functions for parameter checking and with function return values when there is no error handling). They are simply ignored in release builds but can save you a lot of debugging time.