I'm working on moving some types to a matching file refactoring in a VB.NET application written years ago by someone whose no longer with us. He tended to put lots of classes in a file. For example, he'd put a dozen classes into a BaseClases.vb file. It has become hard to find those classes, so I started performing this refactoring to help me as I support the app.
However, every time I'd refactor a type into a separate class file, VS 2019 would generate a message that reads like this:
"The item SomeClass.vb has been cloaked. See output tool window for information on any other errors."
I'd look at the Errors window but didn't see anything obvious. Although there's lots of other errors unrelated to this, so it might be there, and I've missed it in the crowd of errors.
I've searched SO for the phrase "has been cloaked". It only brought up 2 posts, neither of which addressed the situation I'm in.
So, what does it mean to have a new class cloaked? From what is it being cloaked?
Related
SUMMARY:
I need the most efficient workflow to individually edit over 200 files, and have them automatically disappear from the search results as they are updated.
DETAILS:
I am in the process of adding logging throughout a legacy system, and need to update over 200 files, each with their own custom code. I need to edit them one by one, and would like for the updated files to automatically disappear from my working search results after I have completed each one. The idea is to know how many and which ones still need to be updated as I slowly work through them all.
I already had to do something similar a few months ago, but on a much smaller scale, and I used an old-school HACK to do it. I did a search and replace for my keyword, and intentionally misspelled it. I then used the misspelled keyword for my search, and corrected it when editing each file, hence automatically removing it from the list. It "works", but is obviously a TOTAL HACK.
I recently started using IntelliJ IDEA, and am not yet familiar with the more advanced features like Find in File Scopes, Search Structurally, Search Templates, etc., but I am sure there HAS to be a "correct" way to do this in IntelliJ, and I just don't know how.
I am currently using "Find in Files" to work through the list, and recently found "All Changed Files" in the Scope list, which is actually the EXACT OPPOSITE of what I need. Is there a way to show "All UNCHANGED Files"??? That would work PERFECTLY in a pinch! But really, I would rather learn the CORRECT way to do this in IntelliJ.
Thanks!
I just finished skating around that infamous "cannot load main class start" thing, and I got blindsided with a sea of errors:
A friend suggests it might have something to do with com.google, but ultimately can't help me.
I haven't made a single alteration to any of the code so far. Eclipse just started up not being able to run and stayed that way. I think there's a way to fix it but it would require making acute changes at the sight of every single error; work that could be wiped by a cleanup if I'm proved wrong.
Anyone have a clue what the issue is? Thank you for the trouble.
UPDATE: Adding guava as a library relieved the error involving com.google, but threw in a handful of others. This one class file contains 3 of the most common unresolved types I've seen scattered throughout: Logger/LogManagaer, PropertyMap, and CrashReport
Your general problems revolve around not having dependencies in the build path. Eclipse's error messages are pretty clear about this; e.g. if a package name is underlined in red and can't be found, then that means it can't be found, and the obvious solution is to add the library that provides it, so that it can be found.
In virtually all cases here, a Google search for the missing packages and classes will lead you to the packages that contain it.
For each unresolved dependency, find the library, add it to the build path, then move on.
I also suggest consulting the documentation that comes with the source code you are attempting to compile, which often simply lists the dependencies, thus saving you the trouble of hunting them down as you go.
While we could do the internet searches for you and hash this out one step at a time, it's both better and faster for you to do it yourself. Better because if you're messing around with Minecraft source, having at least a basic knowledge of how your tools work is going to help you (I also suggest some of the material at http://docs.oracle.com/javase/tutorial/). Faster because the turnaround time of typing package names into the Google search box is a heck of a lot faster than constantly updating your question here and waiting for replies.
It looks like you are missing the Google Collections package, which now is called Guava.
Download the jar file, and add it as a library.
we're currently customizing iNotes for a customer (platform currently is Domino 9). We almost reached our goals, but one thing that's on our todo list I can't really figure out: they want us to also customize any possible error pages; see the following example screenshot:
This and other similar pages seem to come from the central Forms9.nsf which I'd love to leave as it is. We so far tried domcfg.nsf mappings, but as this is an iNotes internal error it obviously can't work; I also tried to figure out a way to put seomething into our customized Forms9_x.nsf but without any hint this is too abstract for me.
So my questions are:
has anyone ever done this?
what options do we have (apart from "hacking" Forms9.nsf)?
Many thanks in advance...
Update:
After continuing to play with domcfg mappings I suddenly saw a first result; not sure what's the difference to the first attempts, though; maybe moving the error form to Forms9_x.nsf did the trick? I'll keep investigating and post an answer if I can find one...
Alright, this has been an afternoon of wild guessing and hacking along, but finally I think I found it:
first of all, my playing around with domcfg mappings didn't have to do with solving the problem; instead, I just by chance had put my error page form into my Forms9_x.nsf and named it $$ReturnGeneralError (that's simply the name used in Forms9.nsf...; I completely had forgotton about those 4 pre-defined form names back from Domino 5 times).
What did not work was the old method of simply including a text file named MessageString to display the exact error message returned from the server; obviously iNotes is handling those error strings differently.
After a few hours of testing, and comparing codes between the standard iNotes error page and mine I finally found it: include some iNotes specific computed text into the page, in my case that is
#{{MessageString}; html}
See this document for some details (last row in the table)
Hopefully this can help someone else as well...
Where do you store your old classes and files, which you don't longer use in a current project?
I have quite a few classes and files, which are no longer required, but which I would like to keep somewhere in case I need to reuse some of the code later.
Currently, I am just copying and pasting the code in a tool called Code Collector Pro.
However, since this seems not to be the most elegant way of storing old code, I would like to ask you: How do you save your old code?
If you are talking about handy snippets of code that you might use often I store them in Xcode's Code Snippet Library (just drag selected code in to create a snippet.)
Generally though, I delete unused code. If I need it again it will be in my version control system.
I would definitely use a version control system (I'm most familiar with Subversion, but am getting into Git now). If this is code that's worth keeping around then it's code you'll likely use and modify in multiple projects over time. You'll want to be able to review the history of your changes, compare how you used it differently in project A vs. project B, and maintain notes to help refresh your memory and to help in keyword searching when you're trying to find that bit of code you remember using two years ago.
You can set up repositories however makes sense for your work - by project, by code type, etc.
I'm not familiar with Code Collector Pro - if it works as a GUI for a version control system, it may be fine for what you're doing.
Theoretically, the end user should never see internal errors. But in practice, theory and practice differ. So the question is what to show the end user. Now, for the totally non-technical user, you want to show as little as possible ("click here to submit a bug report" kind of things), but for more advanced users, they will want to know if there is a work around, if it's been known for a while, etc. So you want to include some sort of info about what's wrong as well.
The classic way to do this is either an assert with a filename:line-number or a stack trace with the same. Now this is good for the developer because it points him right at the problem; however it has some significant downsides for the user, particularly that it's very cryptic (e.g. unfriendly) and code changes change the error message (Googling for the error only works for this version).
I have a program that I'm planning on writing where I want to address these issues. What I want is a way to attach a unique identity to every assert in such a way that editing the code around the assert won't alter it. (For example, if I cut/paste it to another file, I want the same information to be displayed) Any ideas?
One tack I'm thinking of is to have an enumeration for the errors, but how to make sure that they are never used in more than one place?
(Note: For this question, I'm only looking at errors that are caused by coding errors. Not things that could legitimately happen like bad input. OTOH those errors may be of some interest to the community at large.)
(Note 2: The program in question would be a command line app running on the user's system. But again, that's just my situation.)
(Note 3: the target language is D and I'm very willing to dive into meta-programming. Answers for other languages more than welcome!)
(note 4: I explicitly want to NOT use actual code locations but rather some kind of symbolic names for the errors. This is because if code is altered in practically any way, code locations change.)
Interesting question. A solution I have used several times is this: If it's a fatal error (non-fatal errors should give the user a chance to correct the input, for example), we generate a file with a lot of relevant information: The request variables, headers, internal configuration information and a full backtrace for later debugging. We store this in a file with a generated unique filename (and with the time as a prefix).
For the user, we present a page which explains that an unrecoverable error has occurred, and ask that they include the filename as a reference if they would like to report the bug. A lot easier to debug with all this information from the context of the offending request.
In PHP the debug_backtrace() function is very useful for this. I'm sure there's an equivalent for your platform.
Also remember to send relevant http headers: Probably: HTTP/1.1 500 Internal Server Error
Given a sensible format of the error report file, it's also possible to analyze the errors that users have not reported.
Write a script to grep your entire source tree for uses of these error codes, and then complain if there are duplicates. Run that script as part of your unit tests.
I know nothing about your target language, but this is an interesting question that I have given some thought to and I wanted to add my two cents.
My feeling has always been that messages for hard errors and internal errors should be as useful as possible for the developer to identify the problem & fix it quickly. Most users won't even look at this error message, but the highly sophisticated end users (tech support people perhaps) will often get a pretty good idea what the problem is and even come up with novel workarounds by looking at highly detailed error messages. The key is to make those error messages detailed without being cryptic, and this is more an art than a science.
An example from a Windows program that uses an out-of-proc COM server. If the main program tries to instantiate an object from the COM server and fails with the error message:
"WARNING: Unable to Instantiate
UtilityObject: Error 'Class Not
Registered' in 'CoCreateInstance'"
99% of users will see this and think it is written in Greek. A tech support person may quickly realize that they need ro re-register the COM server. And the developer will know exactly what went wrong.
In order to associate some contextual information with the assertion, in my C++ code I will often use a simple string with the name of the method, or something else that makes it clear where the error occured (I apologize for answering in a language you didn't ask about):
int someFunction()
{
static const std::string loc = "someFunction";
: :
if( somethingWentWrong )
{
WarningMessage(loc.c_str(), "Unable to Instantiate UtilityObject: Error 'Class Not
Registered' in 'CoCreateInstance);
}
}
...which generates:
WARNING [someFunction] : Unable to
Instantiate UtilityObject: Error
'Class Not Registered' in
'CoCreateInstance