Casting UIWindow.rootView to a hosting controller like:
window?.rootViewController as? UIHostingController<MainTabView>
works fine, unless it has environmentObjects.
As my MainTabView has been initialized with .environmentObject, I cannot cast it to UIHostingController<MainTabView>.
When I try to print rootView's type, Xcode tells:
<_TtGC7SwiftUI19UIHostingControllerGVS_15ModifiedContentGS1_V10Panparella11MainTabViewGVS_30_EnvironmentKeyWritingModifierGSqCS2_11GroupsStore___GS4_GSqCS2_18GroupsPresentation____: 0x7fd8afe5da40>
which I suppose is:
UIHostingController<ModifiedContent<MainTabView, _EnvironmentKeyWritingModifier<GroupsStore, GroupsPresentation>>>
but I'm not able to reach _EnvironmentKeyWritingModifier.
Anybody has an idea?
If there is only one EnvironmentObject the following typecast compiles and works fine.
UIHostingController<ModifiedContent<MainTabView, _EnvironmentKeyWritingModifier<Optional<GroupStore>>>>
Even though this is not a complete answer to the question (since there are multiple EnvironmentObjects) I am posting it here in case it might help someone that uses a single EnvironmentObject.
Related
This is my first question ever posted, so please let me know if there is anything that needs changes in my post :)
I am currently working on a dialog that is supposed to let the user change the background-color for some signal plotting. The "wxColourPickerCtrl" seems to do exactly what I need. Since there are multiple plots/pictures to be manipulated, the ColourPickerCtrls are initialized in a loop with the chosen background color as the default value:
for (const auto& [signalName, signalProperties] : properties)
{
wxColourPickerCtrl* selectBackgroundColor = new wxColourPickerCtrl(this, signalProperties.first, signalProperties.second.backgroundColor, wxDefaultPosition, wxDefaultSize);
}
"this" is an object of type SignalPropertiesDialog, which is directly inherited from wxDialog.
I have left out all the necessary sizer stuff, since it's not relevant for the problem (at least imo). "properties" is structured as follows:
std::map<std::string, std::pair<int, GraphPicture::Properties>> signalProperties_;
where GraphPicture::Properties contains the properties I want to manipulate:
struct Properties
{
wxColour backgroundColor{ *wxWHITE };
wxColour lineColor{ *wxBLACK };
int linewidth_px{ 1 };
bool isShown{ true };
};
The application successfully builds but immediately crashes on startup while generating those color picker objects.
wxIshiko has uploaded multiple tutorials and code snippets as examples for various wxWidgets controls, including the wxColourPickerCtrl. So I downloaded the sample code and tried to run it. Surprisingly, it worked.
While running through the code step by step I noticed the following difference:
The wxColourPickerCtrl is based on wxPickerBase. The wxPickerBase is created by calling the constructor of wxColourPickerCtrl (what I am actually doing in my code). During the construction of the wxPickerBase, the desired color is called by the name wxColourDataBase::FindName(const wxColour& color) const where the wxColourBase itself is instantiated. This is where the difference is:
When running the code snippet by wxIshiko, wxColourDataBase is instantiated correctly including the member m_map of type wxStringToColourHashMap* which is set to be NULL.
When running the code written by myself, wxColourDataBase is not correctly instantiated, and thus the member m_map is not set to be NULL, which leads to to the crash.
I have the feeling that there is nothing wrong with the way I set up the wxColourPickerCtrls. I somehow think there is a difference in the solution properties of the projects. I checked those but was not able to find any relevant differences.
I would really appreciate any hint or help since I am completely stuck on that problem.
Thank you very much in advance and have a good one,
Alex
EDIT:
I attached a screeny of the call stack.
Call stack
When does this code run exactly? If it is done after the library initialization (which would be the case, for example, for any code executed in your overridden wxApp::OnInit()), then wxTheColourDatabase really should be already initialized and what you observe should be impossible, i.e. if it happens it means that something is seriously wrong with your library build (e.g. it doesn't match the compiler options used when compiling your applications).
As always with such "impossible" bugs, starting with a known working code and doing bisection by copying parts of your code into the working version until it stops working will usually end up by finding a bug in your code.
After converting over to Swift 3, my AWS iOS App now crashes when being run.
Has anyone seen anything similar after converting over to Swift 3?
Its crashing because you are doing a few things here:
trying to return a method call (which I don't think is possible - but I've never tried it)
application: didFinishLaunching should only ever return true because it's a boolean function as the name suggests. So the return value should be true. If you'd like to override application: didFinishLaunching you can declare that later in your AppDelegate
So here's what you can do... Try deleting the method and slowly type it back until Xcode auto-completes it for you. That will allow you to see what has been depreciated, or what other methods might be useful, also if you haven't yet hit Command + Shift + K to run a clean on your project. Xcode 8 and Swift 3 might have altered a few more things you aren't aware of.
launchOptions is an optional parameter. Doing a forced unwrap with the ! will crash if the value is nil, which it usually is.
I have been researching this, and cannot seem to find anything about it.
We work on CF8. When my coworker tried installing my latest code updates, he started seeing errors that the argument supplied to a function was not of the specified interface type. Worked fine for me. Same set up. Sometimes it works for him. Also have the problem on our dev server.
I have since been able to isolate and reproduce the problem locally.
Here is the set up.
I have 2 mappings on the server:
"webapp/" goes to c:\webroot\
"packages/" goes to c:\webroot\[domain]
Then I created an interface, call it ISubject and a component that implements it, called Person, and saved both under packages. Here is the declaration for Person:
cfcomponent implements="packages.ISubject"
Finally, there is a component, called SubjectMediator with a function, called setSubject, that wants an object of the ISubject interface type. Here is the argument declaration for setSubject:
cfargument name="subject_object" type="packages.ISubject"
To implement:
variables.person = createObject("component", "packages.Person").Init();
variables.subjectMediator = createObject("component", "packages.SubjectMediator ").Init();
variables.subjectMediator.setSubject(variables.person);
That last line throws the error that Person is not of type ISubject. If I do isInstanceOf() on Person against ISubject it validates fine.
So the reason this is happening? Dumping getMetaData(variables.person) shows me that the interface path is webapp.[domain].ISubject. And indeed, if I change the type attribute of the argument to use this path instead of packages.ISubject, all is fine again.
Coldfusion seems to be arbitrarily choosing which mapping to resolve the interface to, and then simply doing a string comparison for check the type argument?
Anyone had to contend with this? I need the webapp mapping, and I cannot change all references to "packages" to "webapp.[domain]." I also am not able in this instance to use an application-specific mapping for webapp. While any of these 3 options would circumvent the issue, I'm hoping someone has some insight...
The best I've got is to set argument type to "any" and then check isInstanceOf() inside the function... Seems like poor form.
Thanks,
Jen
Can you move the contents of the packages mapping to outside the webroot? This seems like the easiest way to fix it.
I have added an object member to InventMovement class and have created one parameter method for the same but following line of code is popping up above error:
movement.parmProdJournalId(this.JournalId);
JournalId parmProdJournalId(JournalId _prodJournalId = prodJournalId)
{
;
prodJournalId = _prodJournalId;
return prodJournalId;
}
After adding the object member and parameter method I have also compile forward InventMovement but no success. Will appreciate if anyone of you could help me in this regard
Rgds
PS: I am doing the same thing which is mentioned in this blog post: http://www.artofcreation.be/2009/04/04/wrong-argument-types-in-variable-assignment/
I stopped the AOS, renamed AXAPD.AOI file and restarted the AOS. This resolved the problem. I got this solution from other forum where also I posted this question.
It is kind of strange, should work.
I could not reproduce your problem, but once had a similar problem. Solved it by re-compiling and synchronizing every involved class and table (more than once).
Also make sure nobody else is using any of these objects, maybe best is to restart the AOS.
EDIT (after comment on question):
Another possibility: it seams that you are also mixing JournalId and ProdJournalId.
I think the parameter and return value of parmProdJournalId should also be ProdJournalId.
Just try this one:
ProdJournalId parmProdJournalId(ProdJournalId _prodJournalId = prodJournalId)
{
;
prodJournalId = _prodJournalId;
return prodJournalId;
}
could not try it myself since I could'nt reproduce the error
If you can't restart the AOS, delete the local cache files of the client might work, i.e. *.auc from:
C:\Documents and Settings\Local Settings\Application Data
So I'm trying to make use of a GtkSourceView in C++ using GtkSourceViewmm, whose documentation and level of support give me the impression that it hasn't been very carefully looked at in a long time. But I'm always an optimist :)
I'm trying to add a SourceView using some code similar to the following:
Glib::RefPtr<gtksourceview::SourceLanguageManager> source_language_manager = gtksourceview::SourceLanguageManager::create();
Glib::RefPtr<gtksourceview::SourceLanguage> source_language = Glib::wrap(gtk_source_language_manager_guess_language(source_language_manager->gobj(), file, NULL));
Glib::RefPtr<gtksourceview::SourceBuffer> source_buffer = gtksourceview::SourceBuffer::create(source_language);
gtksourceview::SourceView* = m_source_view = new gtksourceview::SourceView(source_buffer);
m_vbox.pack_start(*m_source_view);
Unfortunately, it spits out the warning
(algoviz:4992): glibmm-WARNING **:
Failed to wrap object of type
'GtkSourceLanguage'. Hint: this error
is commonly caused by failing to call
a library init() function.
and when I look at it in a debugger, indeed the second line above (the one with the Glib::wrap()) is returning NULL. I have no idea why this is, but I tried to heed the warning by adding Glib::init() to the begining of the program, but that didn't seem to help at all either.
I've tried Google'ing around, but have been unsuccessful. Does anyone know what Glib wants me to init in order to be able to make that wrap call? Or, even better, does anyone know of any working sample code that uses GtkSourceViewmm (not just regular GtkSourceView)? I haven't been able to find any actual sample code, not even on Google Code Search.
Thanks!
It turns out, perhaps not surprisingly, that what I needed to init was:
gtksourceview::init();
After this, I ran into another problem with one of the parameter to gtksourceview::SourceLanguageManager, but this was caused by a genuine bug which I subsequently reported and was promptly fixed. So everything's working great now!
I use gtkmm. Typically you have to initialize things with something like :
_GTKMain = new Gtk::Main(0, 0, false);
Of course do not forget :
delete _GTKMain;
Check here for details :
http://library.gnome.org/devel/gtkmm/2.19/classGtk_1_1Main.html
(Sorry but the link option does not work ...)