Is it possible for a capsule developer to overwrite a library capsule's NoResult dialog by using the same match patterns that are in the library capsule?
Yes. If your capsule’s resource has a match pattern that is equally specific or more specific, it will have priority over the library’s resource.
Related
How can i localize the drop down option for the search mode? I did some digging and was able to adjust the localization for the search form labels but i'm at loss here.
The CMS Module SearchDialog.ascx call the drop down list here, but i can't see where the values come from.
<cms:CMSDropDownList runat="server" ID="drpSearchMode" CssClass="DropDownField" />
Go to the localization App and create resource strings for
"srch.dialog.AllWords"
"srch.dialog.AnyWord"
"srch.dialog.anywordorsynonyms"
"srch.dialog.ExactPhrase"
Believe those are the 4 you need.
I couldn't find official documentation that helps much with this, though there have been articles in the past on older versions. However, one trick I've used previously is to look in the ~/CMSResources/cms.resx file, find the localized string there, and add a new one with the same key to the Localization module in Kentico. That is, add a new resource string in Kentico with the same key (the naming will be different depending on your version of Kentico).
Here's the docs discussing setting up a multilingual interface: https://docs.kentico.com/display/K9/Setting+up+a+multilingual+user+interface
And here's a screenshot of the resx file:
So in your case I'd create a new resource string within Kentico called "srch.dialog.allwords" as an example and that should overwrite and take priority over whatever is in the .resx file, plus you can manage it via the Kentico admin. There may be a quicker or more reliable way to view the list of default resource strings but in my recent installs of Kentico, the list is hidden from the admin interface.
Alternatively, of course, you could manage the resource strings via various .resx files as in the documentation, but I try to manage as much of these pieces via Kentico as possible for convenience.
We are working on plugin for ReSharper and we want to make our plugin extensible. Seems, we should use ShellComponent attribute to do it but we can not find any examples. Could anybody enplane how to define custom extension point and how to manage extension. Example of code of extension point and extension implementation would be very helpful.
Thanks.
If you're looking to write a plugin that can extend ReSharper, you need to tell ReSharper about the classes in your plugin, by marking them with the [ShellComponent] or [SoutionComponent] attributes. These attributes have different lifetimes - a shell component lasts the lifetime of ReSharper itself, and a solution component is created when a solution is opened and disposed when the solution is closed.
To make ReSharper do something useful with your components, they typically have to implement an interface, such as ICodeCompletionItemsProvider, and sometimes have to use a different attribute, such as [CodeCleanupModule] (which itself derives from ShellComponentAttribute). There are many extension points in ReSharper, and the one that's appropriate for you depends on what you're trying to do - refactoring, unit test provider, code cleanup, code completion items, etc. The devguide provides a good introduction to the more common extension points.
But if you want to make your own plugin extensible, then your component needs to work with a kind of provider pattern, by deferring work to multiple provider instances. For example, code cleanup works by deferring to multiple code cleanup modules, each responsible for cleaning up a different aspect of your code (whitespace, ordering, etc). To do this, your component should take in a collection of providers in the constructor. ReSharper's component model will automatically create a collection of these types and pass them to. More specifically, you should have a constructor that takes an IEnumerable<T> or IViewable<T>, where T is the interface of the provider you're going to define and call. The IEnumerable<T> will give you a simple collection of providers, but IViewable<T> represents an observable collection, and allows you to subscribe to notifications of new providers being made available from the component model.
My toolchain (Realview) does not have implementation of unistd.h, I have a code that I need to use that is using unistd.h, some function like access, open.
So I need to implement this functions by myself.
My question is, is there another alternative or some reference (except the function description, found here) that I can use in order to port/implement these functions?
What is the correct way to do that? It's my first time posting.
The "function description" you link to has the page title "The Open Group Base Specifications Issue 6", which indicates that it's perhaps a bit more of a heavy-weight than just being a mere description.
If you implement a function that fulfills all the text on that page correctly, chances are you've managed to re-implement it in a compatible way, so that programs complying to the same standard will build and work.
Not sure what else you feel you would need.
I use a flat document list for certain document types and I want to give my users a possiblity to jump to the parent folder of this document.
Is there a column that contains this information? I couldn't find one.
No, there isn't a column or UI affordance for the parent folder in either a document library or the document library web part, nor is there a way to create a calculated field (without creating a totally custom field in code) - MSFT intended people to use the breadcrumbs I suppose. There are plenty of third party web parts out there for sale that provide this functionality (sort of) -but I haven't found one yet that I would recommend.
Is it something like this you are looking for?
As I couldn't find an easy solution for my problem, I just coded that field type myself.
Indeed, there is nothing OOTB that provides this information. At best, you can 'guess' the parent folder by getting the second-to-last segment of the FileRef column (the file's own URL):
▼ this one
/web/web/list/folder/folder/file.ext
Of course, that only works when you can have a reasonable expectation the file will actually be at least one folder deep. We have some limited cases where this works.
I am new to MFC and I need to build a multi-language application that should be able to change the language at runtime.
AFAIK the common way for internationalization with MFC is to create resource-only DLLs. But there seems to be no simple way (that means, load DLL, call some function, and MFC updates all stuff automatically or something like that) to switch resource-DLLs at runtime, right?
So I will have to update all controls and so on manually. I already managed to load strings from the string-table of a DLL but since captions of controls like buttons are stored in the corresponding dialog (if I trust my resource-hacker :)) I thought there must be a way to load them and avoid storing an additional string in the string-table manually.
Or is there another way I don't know about?
If it makes any difference...I have to use MS embedded visual c++ 4
I work on a large localized MFC project. Here is our strategy:
A dictionary of key -> localized string, specific to each language. There are a few ways to implement this, more later.
Control IDs or captions in the dialog resource are set to the key used to look up the translation
Create a base CDialog, CFormView, etc and in at init call ::EnumChildWindows. In the callback, look up the translation and replace the control's caption with the translation.
For your dictionary, you can go a few ways.
If you want to rely on the built-in localized resource selection and string tables, you have to somehow match the control to the string ID. You can carefully ensure that the control ID matches the string ID, or you can ASCII-encode the ID in the caption and then use atoi to parse the int value.
You can forgo the built-in localized string table deal and maintain your own string -> string dictionary for each language. This lets you set the caption to the non-localized string in the resource which makes layout easier (although you'll still need to test in all languages.) It will require you to do your own "dependency injection" to make sure you load up the right dictionary. You want to be able to release updated/additional languages without rebuilding the core binaries.
If you don't want to require a restart of the application (by far the easiest solution, and the one you should use IMO), you can use resource dll's and recreate the main windows when the user switches languages. That way MFC will recreate the menus etc. in the new language. New dialogs will be displayed in the new language already anyway, from the moment you've switched the resource handle around.
I'm not sure how this relates to the embedded world, my experiences are from the desktop MFC.