I am currently working on fixing some BestPractice-Warnings on a bigger project. There i have a few instances where forms are called and are awaited before doing more stuff, this is mostly some dialogs. To await form the following code is used very often:
Object formRun;
//declare args and stuf...
formRun = classfactory.formRunClass(args);
formRun.init();
//call methods on formRun (display,run,etc...)
formRun.wait();
The problem i am facing now is that 'wait()' seems to be deprecated and i don't get how to replace or fix this. I have seen that some devs declared the form as 'Object' to get rid of this warning (didn't work by the way, this will still be detected), but this is a late-bound-call which should also be avoided...
Has anyone else had this issue ? i tried calling this method using the system.reflection namespace but this doesn't look right and is also much more code in x++ than should be needed for such a simple task.
TLDR
I think this is a false positive from the best practice checks. To get rid of the best practice warnings, you can add them to the list of suppressed best practices or add a best practice suppression in code.
Details
In Deprecated APIs (June 2017) it says for the wait method of Object:
Overview
Used to block and wait for an interaction/operation and notify to
unblock.
Reason for deprecation
These calls are deprecated for all objects except formRun and it’s
derivatives.
Migration notes
Calls to these APIs from formRun or it’s derivatives are allowed.
Calls to these APIs from any other object should be removed.
When you do a metadata search for code:"formRun.wait()", you will also get a lot of results (more than 1000 on version 8.0). This is further indication that the method is not deprecated for FormRun.
That said, you may want to take a look at the following link which mentions a formRun.lifecycleHelper() to which event handlers can be added. I haven't personally tried this so far, but it may be applicable to your case.
FormRun.wait, Box and ChangeCompany - a poor cocktail
Related
Upgrading AngleSharp from 0.9.6 to 0.9.9 I have this line of code no longer compiling:
return configuration.With(LoaderService(new[] { requester }));
It complains that LoaderService does not exist in the current context. So what happened to LoaderService? Is there a replacement? Does it still exist but just somewhere else?
Good question. Sorry for being late to the party, but even though you may have solved your problem someone else is having a hard time figuring it out.
LoaderService was essentially just a helper to create a loader. But having a service for anything creating a little thing would be overkill and not scale much. Also AngleSharp.Core would need to define all these. So, instead a generic mechanism was introduced, which allows registering such "creator services" via Func<IBrowsingContext, TService>.
However, to solve your piece of code I guess the following line would do the trick:
return configuration.WithDefaultLoader(requesters: requester);
This registers the default loader creator services (one for documents, one for resources inside documents) with the default options (options involve some middleware etc.).
Under the hood (besides some other things) the following is happening:
// just one example, config.Filter is created based on the passed in options
return configuration.With<IDocumentLoader>(ctx => new DocumentLoader(ctx, config.Filter));
I am new to gRPC and trying to use it in my existing system. However, I get this unused parameter error while compiling it.
server_grpc.cc:100:39: error: unused parameter ‘context’[-Werror=unused-parameter]
Status MyFunc(ServerContext* context, const QueryRequest* request,
Probably the context parameter is used in some other cases. But, in simple hello world type of example it is not used. Is there a way to compile the protocol buffer without generating the ServerContext parameter ?
I know I can make the compiler ignore warning messages. But, just wondering if it can be done without affecting the way my system is being compiled right now.
I would like to know how the context is used ? It would be great if anybody can give pointers to how to use this context. I might find a use of it in my work.
The ServerContext is provided to, well, add context for every RPC you get. It'll allow you to tweak certain aspects of the RPC, such as deal with authentication, or add metadata to your response back to the client. You may or may not need that parameter, obviously, depending on your needs.
We didn't want to add an option for this specifically, because that'd complexify the code and tool for little benefit, so the code generator and the function signature force you to have that parameter at all times. Now this isn't really a big deal, because in C++, you can specifically ask your compiler to ignore a parameter in a specific instance, for example with the following:
Status SayHello(ServerContext* context, const HelloRequest* request,
HelloReply* reply) override {
(void) context; // ignore that variable without causing warnings
std::string prefix("Hello ");
reply->set_message(prefix + request->name());
return Status::OK;
}
And that's how I'd suggest you to take care of that warning in that specific instance, without causing your whole project to not have warnings enabled.
How can I tell the Closure Compiler not to rename an inner function? E.g., given this code:
function aMeaninglessName() {
function someMeaningfulName() {
}
return someMeaningfulName;
}
...I'm fine with Closure renaming the outer function (I actively want it to, to save space), but I want the function name someMeaningfulName left alone (so that the name shown in call stacks for it is "someMeaningfulName", not "a" or whatever). This despite the fact that the code calling it will be doing so via the reference returned by the factory function, not by the name in the code. E.g., this is purely for debugging support.
Note that I want the function to have that actual name, not be anonymous and assigned to some property using that name, so for instance this is not a duplicate of this other question.
This somewhat obscure use case doesn't seem to be covered by either the externs or exports functionality. (I was kind of hoping there'd be some annotation I could throw at it.) But I'm no Closure Compiler guru, I'm hoping some of you are. Naturally, if there's just no way to do that, that's an acceptable answer.
(The use case is a library that creates functions in response to calls into it. I want to provide a version of the library that's been pre-compressed by Closure with SIMPLE_OPTIMIZATIONS, but if someone is using that copy of the library with their own uncompressed code and single-stepping into the function in a debugger [or other similar operations], I want them to see the meaningful name. I could get around it with eval, or manually edit the compressed result [in fact, the context is sufficiently unique I could throw a sed script at it], but that's awkward and frankly takes us into "not worth bothering" territory, hence looking for a simple, low-maintenance way.)
There is no simple way to do this. You would have to create a custom subclass of the CodingConvention class to indicate that your methods are "local" externs (support for this was added to handle the Prototype library). It is possible that InlineVariables, InlineFunctions, or RemoveUsedVariables will still try to remove the name and would also need to be fixed up.
Another approach is to use the source maps to remap the stack traces to the original source.
read the following section
https://developers.google.com/closure/compiler/docs/api-tutorial3#export
Two options basically, use object['functionName'] = obj.functionName or the better way
use exportSymbol and exportProperty both on the goog object, here is the docs link for that
http://closure-library.googlecode.com/svn/docs/closure_goog_base.js.html
-- edit
ah, i see now, my first answer is not so great for you. The compiler has some interesting flags, the one which might interest you is DEBUG, which you can pass variables into the compiler which will allow you to drop some debugging annotations in via logging or just a string which does nothing since you are using simple mode.
so if you are using closure you can debug against a development version which is just a page built with dependiencies resolved. we also the drop the following in our code
if(DEBUG){
logger.info('pack.age.info.prototype.func');
}
Regularly during my application run, I get
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at mx.managers::SystemManager/stageEventHandler()[C:\autobuild\3.4.0\frameworks\projects\framework\src\mx\managers\SystemManager.as:5649]
This is the full stack trace. Obviously, I guess there is something wrong, but I can't understand what.
Is there any way for me to find the origin of that bad behaviour ?
EDIT
Having added my SDK sources to my debugger, I can now say precisely which line it is :
private function stageEventHandler(event:Event):void
{
if (event.target is Stage)
mouseCatcher.dispatchEvent(event); // This is line 5649
}
mouseCatcher is indeed null. The current event target is indeed a Stage object, and event type contains the "deactivate" String. As event occurs at application startup (before I try to do any kind of user interaction), I guess it's a kind of initialization bug, but where ? and why ?
Look at the source code, this is always your best option. The 3.4 SDK is open source (datavisualization and the flash player itself aside) and you probably already have the source for it in your FlashBuilder/FlexBuilder install/sdks folder. Use grep or windows grep to find the file in question (or find, whatever floats your boat). Open the SystemManager file and check what's happening at that line, check for calls to the method (if it's public use grep again, if it's private you just need to look within the SystemManager). Try to understand why it gets to this point, as pointed out by some others it's likely a timing related issue where you're trying to access something before it has been assigned, in this case the SystemManager, you probably need to defer whatever action you're taking that is causing the error to a later part of the life-cycle (if you're using initialize event or pre-initialize try on creationComplete instead since that will be dispatched after the createChildren method is called).
Note: Mine is located here
C:\CleanFS\SDKs\flex\3.4.0.9271\frameworks\projects\framework\src\mx\managers
In my copy of SystemManager with the version of the SDK I have that line number doesn't make any sense since it's a block closure not an executable line so you'll have to look at your specific version.
It looks like you are using the Flex 3.4 SDK. Are you listening for the ADDED_TO_STAGE event when the application loads? Or doing anything with the Stage object on load? If so, you might be hitting a bug specific to the 3.4 SDK:
http://bugs.adobe.com/jira/browse/SDK-23332
The most obvious solution is to swap out the 3.4 SDK for a later version (3.4A, 3.5 or 3.6). You can do that here: http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3
All of your code should be backwards compatable with the newer Flex 3 SDKs.
I am using MVVM Light and am using Messages to communicate between ViewModels to let a ViewModel know when it is ok to execute something. My problem is that I register for a message and then it receives it multiple times. so to keep from my program executing something more than once I have to create boolean flags to see if it has already been recieved. Any idea why it does this and how I can stop it?
Make sure you unregister your message handlers once you do not need them anymore. The Messenger keeps a reference to the registered methods and this prevents them from being garbage collected.
Therefore, for ViewModels: make sure that you call Cleanup once you done (or implement IDisposable and call Cleanup from there).
For Views (Controls, Windows, or similar) call Messenger.Unregister in an event that occurs on the teardown of the view, e.g. the Unloaded event.
This is a known behaviour of the MVVM and has been discussed in several places.
Very old question but I solved the problem by doing this:
static bool isRegistered = false;
and then, in the constructor:
if( !isRegistered )
{
Messenger.Default.Register<MyMessage>(this, OnMessageReceived);
isRegisterd = true;
}
I have seen this issue before. It had to do with the Messenger.Default.Register being called more than once. The MVVMLight Messenger class will register the same item 'x' number of times. This is why when you call the Send you get it many times.
Anyone know how to prevent MVVMLight from registering multiple times?
really old but thought I would answer just in case somebody needs it. I was fairly new to silverlight at the time and the issue ended up being a memory leak as the viewModel, which had multiple instances, was still in memory.
As other contributors mentioned, the same message is being registered multiple times. I have noticed this behavior taking place while navigating to View X then navigating back to View Z where the message is registered in the constructor of the Z ViewModel. One solution is to set the NavigationCacheMode property to Required
<Page
........
........
NavigationCacheMode="Required">