User forums > Help
wxWidgets Setting textbox value can't update programmatically
BlueHazzard:
To solve your problem i would recommend to make the App object accessible in the wxFrame code. You can use
http://docs.wxwidgets.org/trunk/group__group__funcmacro__rtti.html#ga1523a2d553dea288d66cd35e8a0ffd5c
in the CB_SRList_wxApp.h file
This will look like this:
--- Code: ---
#ifndef CB_SRLIST_WXAPP_H
#define CB_SRLIST_WXAPP_H
#include <wx/app.h>
class CB_SRList_wxApp : public wxApp
{
private:
wxString m_cmd_line;
public:
virtual bool OnInit();
wxString GetCmdLine() {return m_cmd_line;};
};
DECLARE_APP(CB_SRList_wxApp);
#endif // CB_SRLIST_WXAPP_H
--- End code ---
NOTE: If you are using wx2.8 you HAVE to use DECLARE_APP() and not wxDECLARE_APP()
in the application file:
--- Code: ---bool CB_SRList_wxApp::OnInit()
{
// Do your command line parsing here and safe it in m_cmd_line, for example:
if(argc > 1)
m_cmd_line = wxString(argv[1]);
//(*AppInitialize
bool wxsOK = true;
wxInitAllImageHandlers();
if ( wxsOK )
{
CB_SRList_wxFrame* Frame = new CB_SRList_wxFrame(0);
Frame->Show();
SetTopWindow(Frame);
}
//*)
}
--- End code ---
Now in your frame code:
--- Code: ---#incldue "CB_SRList_wxApp.h"
CB_SRList_wxFrame::CB_SRList_wxFrame(wxWindow* parent,wxWindowID id)
{
void SetValue_of_FileName_TextCtrl1( wxString t); // DrO
//(*Initialize(CB_SRList_wxFrame)
// wxSmith bla bla
//*)
FileName_TextCtrl1->SetValue(wxGetApp().GetCmdLine());
}
--- End code ---
i know it is not 100% what you want, but this works with wxSmith and encapsulates parsing of data and showing data nicely (parsing in the app class, but showing in the frame (Doc/View model ;) ) )
And no, this is not a wrong way, its the way of wxSmith. As i said before: all roads lead to Rome, but sometimes one road is longer than the other...
[EDIT:] NOTE: i don't have compiled explicitly this code, so there are possibly a view syntax errors... But the approach is tested and works...
DrOli:
Many thanks for the thoughtful and detailed response.
First, an apology: In providing the code in my previous response, I erred. Notably, our code is actually very much longer as it includes a vast number of comments and "experimental" sections. I had stripped all the non-essential bits for clarity ... but clearly I messed up, resulting with a couple of spurious bits in the posting.
... this caused you to be distracted, and to waste time ... my bad! FYI, I have had to put some considerable monies into our "swear jar" :-(
Also, some bits included demonstrate desperation. For example, we know enough about CPP that the line should be:
CB_SRList_wxFrame.SetValue_of_FileName_TextCtrl1( InitialFileName_wxs);
not
CB_SRList_wxFrame::SetValue_of_FileName_TextCtrl1( InitialFileName_wxs);
... but had erroneously left the "wrong experiment" in the submitted code ... again, my bad!
Finally, sorry about my ignorance regarding "code display" in the forum, I'll try in this post to see if I've sussed it.
Now for some GOOD news, we think.
We have obtained an alternate solution from wxWidgets, and which is massively simpler/more elegant, but which may have some risks in the context of CB's Wizard/scripts.
In particular, their solution is simply to change the original CB_SRList_wxApp.cpp code from:
--- Code: --- //(*AppInitialize
bool wxsOK = true;
wxInitAllImageHandlers();
if ( wxsOK )
{
CB_SRList_wxFrame* Frame = new CB_SRList_wxFrame(0);
SetTopWindow(Frame);
}
//*)
--- End code ---
to
--- Code: --- //(*AppInitialize
bool wxsOK = true;
wxInitAllImageHandlers();
if ( wxsOK )
{
CB_SRList_wxFrame* Frame = new CB_SRList_wxFrame(0);
Frame->SetValue_of_FileName_TextCtrl1( InitialFileName_wxs ); //! DrO
Frame->Show(); //! DrO
SetTopWindow(Frame);
}
//*)
--- End code ---
This works beautifully ... though, of course, it is between //("...//") markers, and so may lead to "CB/script risk". We don't really understand the "CB/script risk" since in some places (especially in the "main", CB is utterly narcissistic regarding these blocks, while ... so far ... this bit of code in "Apps" has not been "molested" by CB, even after several specific tests altering the gui, to see if we would loose the (extra) code. Presumably, there may be certain actions in CB that would then also "molest" the App code, but perhaps we have not as yet happened across them.
Of course, we have taken note of your statement that we should not place things inside those CB markers ... but given the elegance and simplicity of wxWidget's solution, we were wondering if you would still recommend against the type of approach here (we would like to avoid your solution on the grounds that we are neophytes and don't fully grasp all the bits yet, and it is much more expensive ... particularly for what is coming next).
Moreover, getting a bit of text to a gui text field is just the first and "easy" bit. Next, we need to link the App to a DLL, which returns the array that fills the grid on the gui. That requires a lot of code. So if there is risk of loosing a lot of code due to "CB/script risk", we would like to know more about it.
... if you feel the risk is too great, then we will take the plunge and the extra expense, but obviously would wish to avoid that if practical.
Please advise.
P.S. Thanks for the tip Re the FileName_TextCtrl1->SetValue(wxGetApp().GetCmdLine()); approach. In the event, as the filename must be passed to a DLL written in Fortran, which does the "actual calculation/processing", and which is via "bind(c)", our meagre skills only know enough to rely on a char variable that we know how to pass to the DLL. As such, with our limited c/wx knowledge, we are obliged to use the approach taken to retrieve the command line to char**, and convert to wxString only for the txtctrl, but really requiring the char** for the DLL.
DrOli:
ooops ... dreadfully sorry, and please disregard much of the earlier post.
In the event, we had already previously implemented a process that equates to your solution. Unfortunately, and I suppose due to the many permutations we were testing (and as had reported earlier), with an approach like yours, we had the cmd line arg evaluated in OnInit(), but it was evaluated after the " //("...//") " bits. Indeed, we had commented that we did not understand why that was not working as we expected the OnInit() to be completed in totality before it returned to "main" (e.g. we were cout'ing at every stage, and did not understand why the setvalue in main was null, given that the var was assigned in OnInit() ... or so we thought).
... it seems, if now we have it correct, that " //("...//") " block has set frame (Frame->Show) directive, and that is, it seems, the "end" of the OnInit() processing.
As soon as we moved the cmd arg eval prior to the " //("...//") " in the OnInit, and removed the setvalue from OnInit, the setvalue we had already in the "main" worked correctly.
Incidentally, on further exchange with the wxWidget chaps, they also suggested moving the setvalue from the OnInit to the "main" (frame constructor), as you have suggested (and we already had, but with the messed up arg assignment in OnInit())
... to make a long story short, we have actually implemented your solution already before your solution was posted, but had messed up on the order of operations in OnInit() ... as it did not occur to us that it would stop processing prior to the end of OnInit().
In any case ... SOLVED ... whoo hoo ... many thanks for all the effort.
markp:
I know it's been a year since this was discussed, but for those who, like I, did a search for 'wxsmith argc' this is where you'll probably end up.
I would have liked to a see a simple way to access the command line arguments from the Frame area of a wxSmith project but no luck from what I've read above - so what I did is.
Pass argc and argv to the Frame constructor - in the wxApp::OnInit() function
--- Code: ---change new projectFrame(0);
to new projectFrame(0, 0, argc, argv);
add ' ,int c = 0, char** v = NULL ' to the constructor arguments in the projectMain.cpp and projectMain.h files.
add int argc and char** argv to the public area of the Frame class,
add argc = c; and argv = v; to the constructor method.
--- End code ---
Now you can access all the command line arguments you want in any projectFrame member or event routine.
Hope it helps.
Navigation
[0] Message Index
[*] Previous page
Go to full version