|
It doesn't work like that.
There are plenty of sites where you can hire someone to do your work for you. This is not one of them.
We're happy to help with specific problems in code you have written. But this is not a "do my work for me" or a "convert this code for me" type of site.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Can someone please tell me how I can debug a C++ DLL from within Tradestation 10 by attaching VS2022 to the Tradestation process?
I can compile a DLL successfully and call a function from it for display within a Tradestation workspace. After a LOT of time spent browsing around on various MicroSoft learning pages etc etc, I have arrived at the following method but cannot get Visual Studio 2022 to load symbols or recognize the required .PDB file(s).
To complicate matters the DLL must be a release version and reside in the Tradestation system file for it to work with Tradestation. It is my understanding that this is ok so long as the relevent .pdb files are available to enable debugging. Here is my methodology so far:
1. Compile the C++ DLL in Visual Studio 2022 in RELEASE mode as specified for use in tradestation.
2. Set post build to copy MyDLL.dll and MyDLL.pdb to C:\Program Files (x86)\TradeStation 10.0\Program
3. Indicator using function from MyDLL.dll plots ok - great!
4. Set breakpoint in C++ code within function in Visual Studio 2022: breakpoint shows no errors.
5. Attempt to debug in release mode in VS 2022 by attaching Tradestation process using indicator/MyDLL to be debugged: Debug -> Attach to Process... -> ORPlat.exe
++++ Now things do not go to plan ++++++++
6. MyDLL.dll not listed in Modules window
7. Numerous messages appear in the Modules window such as:
ORPlat.exe C:\Program Files (x86)\TradeStation 10.0\Program\ORPlat.exe Cannot find or open the PDB file.
8. MyDLL.dll shows up as being loaded ok using DebugView
Compiler settings in VS2022 are:
/ifcOutput "Release\" /GS /GL /analyze- /W3 /Gy /Zc:wchar_t /Zi /Gm- /Od /Fd"Release\vc143.pdb" /Zc:inline /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL" /D "GLOBALVARIABLE23_EXPORTS" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /Oi /MT /FC /Fa"Release\" /EHsc /nologo /Fo"Release\" /Ot /Fp"Release\Future DLL.pch" /diagnostics:column
Am I flogging a dead horse here? Is it impossible to debug MyDLL.dll from within Visual Studio by attaching it to the Tradestation process (ORPlat.exe)? If it is not possible (such as debugging only from within Tradestation; how do you attempt serious debugging in complex C++ code within your MyDLL.dll functions?
Any help on this greatly appreciated!
Cheers
|
|
|
|
|
PaulS_UK wrote: 6. MyDLL.dll not listed in Modules window Sounds to me like your DLL is not being loaded by the process. Is there something you need to do to cause it to load the DLL, like maybe use a particular feature?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
PaulS_UK wrote: how do you attempt serious debugging in complex C++ code within your MyDLL.dll functions
Any language - I use logging.
Last time I did C++ I rolled my own. But googling I see Log4cxx and Log4cpp. I might go with the second but I would do more research first.
|
|
|
|
|
0
I need to read the TextBox input, my username and password work as below, but the file input and file output require another step to convert a string that can open the files.
I've tried every example I can find, cstring numerous times.I can't believe no one uses a textbox to open a file. Why can't i get an answer? Will someone please read this question and answer it. I see that some questions get numerous answers and I can't even get one answer. Please help me!
THESE 2 BELOW WORK private: System::Void usernameTextBox_TextChanged(System::Object^ sender, System::EventArgs^ e) { msclr::interop::marshal_context context; std::string myUsername = context.marshal_asstd::string(usernameTextString); }
private: System::Void passwordTextBox_TextChanged(System::Object^ sender, System::EventArgs^ e) {
msclr::interop::marshal_context context;
std::string myPassword = context.marshal_as<std::string>(passwordTextString);
}
THESE 2 BELOW NEED AN ADDITIONAL LINE OF CODE TO OPEN THE FILES private: System::Void myInfileTextBox_TextChanged(System::Object^ sender, System::EventArgs^ e) { msclr::interop::marshal_context context; std::string myInfile = context.marshal_asstd::string(myInfileTextString); }
private: System::Void myOutfileTextBox_TextChanged(System::Object^ sender, System::EventArgs^ e) {
msclr::interop::marshal_context context;
std::string myOutfile = context.marshal_as<std::string>(myOutfileTextString);
}
|
|
|
|
|
|
Hi,
in my MFC DLL, pMyDLLCWnd is pointer to a class driver from CWnd.
When CDialog is linked to DLL, timer starts.
When console is linked to DLL, same timer does not start.
pMyDLLCWnd->Settimer(ID,t,NULL)
DLL has wm_timer message handler.
|
|
|
|
|
Where do you create the window the pMyDLLCWnd points to: in a DLL or where?
|
|
|
|
|
|
Could it be that you're using a timer that is based upon window messages, and there are no window messages in a console application?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
in DLL:
pMyDLLCWnd is pointer to a DLL class derived from CWnd.
pMyDLLCWnd->SetTimer(..)
There are windows message handler WM_TIMER in DLL.
In console there are no windows?.
So, create a dummy window in console, pass its handle to the DLL?.Or, create a GetMessage while loop?.
I have not tried this since I changed the design but like to try it.
|
|
|
|
|
Can that message handler in the DLL be set up to call a function of yours?
"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
|
|
|
|
|
I'm sorry, my answer was a quick guess. That's why I put a question mark after it.
Truth is I'm not sure.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hi,
In my MFC project, I get crash as follows:
1. i call MyCreate() then MyUnCreate()
2. calling MyCreate() the second time, causes crash at AfxRegisterWndClass below.
sudo code provided:
CMyCwndSub is derived from CWnd.
in another file:
CMyCwndSub *p;
void MyCreate()
{
p->new CMyCwndSub;
CString m = AfxRegisterWndClass(0); p->CreateEx(0, m, -T"MyWndWin",0,0,0,0,0,NULL,0);
.
.
.
}
void MyUnCreate()
{
delete p;
p = NULL;
}
|
|
|
|
|
|
would this work?.
void MyUnCreate()
{
::UnregisterClass(_T("MyWndWin"), AfxGetInstanceHndle());
delete p;
p = NULL;
}
|
|
|
|
|
Didn't you test it?
Also you must pass to UnregisterClass the className returned by AfxRegisterWndClass(...), not the caption of your window!
modified 13-Jun-24 11:25am.
|
|
|
|
|
I did the following and still crashed. Maybe the AfxRegisterWndClass is set to release class automatically at the end when library exits. ?
void MyUnCreate()
{
::UnregisterClass(ClassName, AfxGetInstanceHandle());
delete p;
p = NULL;
}
|
|
|
|
|
etechX2 wrote: Maybe the AfxRegisterWndClass is set to release class automatically at the end when library exits. ?
1. Please read the Microsoft documentation about AfxRegisterWndClass;
2. Why are you trying to unregister and then reregister already registered Class? just save its name and then use it again!
|
|
|
|
|
Hi Guys,
I have recently came across one scenario where I have to insert a user defined key in a c++ map. that class looks like this
class key
{
int id;
string name;
};
map is like map<key,int>
I'll overload "operator<" function and will sort out based on "id" which will works fine, but the condition is like, if there are 2 entry with same ID but with a different name, for ex. {"50", Jack} and {"50", John}
As both the values have SAME ID and different name, map should make an entry for both.
Only in the case of combination of same ID and same name, it shouldn't allow the entry.
bool operator<(key& temp)
{
if(id < temp.id)
{
return true;
}
if( id == temp.id)
return name < temp.name;
}
its not working properly, its overriding the last entry if same ID is there.
Please help me out
-- modified 10-Jun-24 15:02pm.
|
|
|
|
|
Try std::multimap. It does exactly what you want.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Disclaimer: What I'm about to talk about is C++ implementation details. C++ compilers aren't *necessarily* implemented the way I describe in theory, but in practice they virtually all are - at least the major ones, AFAIK.
C++ is very "lexical" in how it works.
The bones of the OOP, method overloading, and template instantiations are implemented in part through name mangling, which is fundamentally lexical vs having a different, say, integer or binary key for each of the above.
The template instantiations work like a mail merge, but with "smart" template parameters (by smart I mean, not simply lexical but type aware, compiler resolved). The actual template code is basically search and replaced, but template resolution is "smart" (similar to how i used the word above) in that it can resolve recursively and stuff, so it's a bit more complicated than strict search replace, but it's close.
C++ in many ways (but not all ways) is C with syntactic sugar.
C++ OOP isn't special. It's basically C with a combination of name mangling, and hiding the first (implicit) this argument
consider the following
#include <stdio.h>
class foo {
int m_bar;
public:
foo() : m_bar(0) {
}
int bar() const { return this->m_bar; }
void bar( int value) { this->m_bar = value; }
};
typedef struct _foo_c {
int bar;
} foo_c_t;
void foo_foo_foo_c_t(foo_c_t* handle) {
handle->bar = 0;
}
int foo_bar_foo_c_t(foo_c_t* handle) {
return handle->bar;
}
void foo_bar_foo_c_t_int(foo_c_t* handle, int value) {
handle->bar = value;
}
int main(int argc, char** argv) {
foo foo_cpp;
foo_cpp.bar(42);
foo_c_t foo_c;
foo_foo_foo_c_t(&foo_c);
foo_bar_foo_c_t_int(&foo_c,42);
printf("foo_cpp: %d, foo_c: %d\n",foo_cpp.bar(),foo_bar_foo_c_t(&foo_c));
return 0;
}
That's C++ and its rough equivalent as C code, and the C is similar to how the C++ resolves internally.
I feel like understanding that helped me greatly understand C++.
I'm wondering if any other C++ developers out there had a similar epiphany about the language that helped them understand it better, and what it was.
Part of it is I was thinking of compiling an article about this, but the above isn't enough by itself.
I'm hoping to add more content, but maybe some of you who have had similar epiphanies about the language could inspire more content along this vein. If so, please put it in a reply. Thanks!
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
honey the codewitch wrote: C++ in many ways (but not all ways) is C with syntactic sugar.
One might argue that C is just assembler with syntactic sugar too.
I think you could make the same argument about any of the C Family of languages: C, C++, Objective C, Java, C# etc. Perhaps even Go and Rust?
And, of course, we can't forget that Bjarne Stroustrup's original work on C++ (C with classes) was implemented with Cfront - Wikipedia, which converted C++ code to plain C.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
No. In C# a class is first class, binary structured as a class to the CLI, with metadata, etc.
In C++, a class is little more than what I demonstrated with code above - a bunch of renamed methods with a hidden this parameter.
I guess I wasn't clear. I even produced code to try to make it clear. Meh.
But I guess yeah - Cfront existed. C++ is C with syntactic sugar.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
modified 8-Jun-24 9:46am.
|
|
|
|
|
Cfront (I had forgotten that name!) taught me "everything" about OO. I guess I should say "all the fundamentals" - OO has developed since then.
I had been OO programming since 1979, student exercises in Simula, but our Compiler Construction course did not address OO at all. (Maybe later editions of the dragon book did, but not the current edition when we were students.) So, when we got a chance to see in cleartext how a compiler realized OO mechanisms, it was like a revelation to us.
My memory and calendar suggest that we had access to the C++ compiler earlier than 1983, the official release date of Cfront - maybe it was in 1982. It wasn't uncommon for professors and students swimming across the pond to return with all sorts of new and fancy software discretely hidden in their briefcases. Maybe the 'Cfront' name wasn't assigned to it, and that is why I don't remember the name.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|