I am working on an MBCS app using MFC. I am trying to support Asian languages. For the purposes of this discussion, we'll say I'm trying to support Chinese. I am able to support Pop up dialogs via MessageBoxW and Dialog SCREENs by pasting Chinese characters directly into the RC file. I can't get file menus to work using either resource view or editing the RC file directly. Whenever I type in ANY Asian character, the screen shows ???. One ? for each character. I have tried modifying the menu in C++ using ModifyMenuW. I get more question marks. Visual Studio shows everything working, and the RC file is unicode (UTF-16). I can't easily convert my project to unicode mode. Spanish, French, and German all works fine (one of the Essets in German doesn't work, but that isn't a show stopper). What should I try next?
Thanks in advance!
Well, the easy answer would be change the application to Unicode, but this is not always simple, or possible at all.
Concerning using Unicode in a MBCS application, some things are possible and some others not. For example, I have made a MBCS application displaying and editing translations of program strings (messages, menues etc) in a ListView control, however ListView does have a specific message to turn it to Unicode (LVM_SETUNICODEFORMAT) and support operations (see also CCM_SETUNICODEFORMAT). Menus aren't controls though, but they do have "wide" (Unicode) functions.
If you want to use Unicode in your application, there are some tests you need to make. Success is not guaranteeded, but you can at least draw some conclusions and determine whether what you want to do is possible.
Test1:
You mentioned trying ModifyMenuW(), but this will try to modify an existing menu. Instead, try InsertMenuW() or InsertMenuItemW(). Any unicode string should be displayed properly, so try not just Chinese, but other laguages too (eg Greek or Russian). And btw, I can't see how French works and German doesn't (they use the same codepage - West European). What's the system codepage of your test-machine?
Test2: (if the above has failed)
Try changing the whole menu (SetMenu()) with having a single (unicode) menu item as its root.
Test3: (if the above have failed)
Then you need to check whether the window containing the menu must be Unicode. Create a simple "Hello World" Win32 application, or find a sample, if Visual Studio does not do this for you (these basically register the window class, create the main window and start the message-loop) - you must add a menu too, using the "wide" version of the menu functions explicitly. If this doesn't work, try changing the code that creates the window to unicode. This way you will know whether you need a unicode window, to own the menu.
Please make these tests and let us know the results. I will further post if needed.
I have a project with several classes which partly share functions while at other times the functions are different in code, but use the same name.
When hovering over a function name, Sublime highlights every file and line where that definition is found.
In my opinion it would be better if it actually included which class the different highlights belong to.
Is it possible to edit this in some way ?
Assume systems.js contains 4 different classes (1 base, 3 children). I would like to append or prepend the shown strings by the class definition (fetchable via prototype).
The hover popup mentioned in your question is powered by Sublime's internal symbol index, which is created in combination with the syntax definition that's used to syntax highlight files that you're editing. The Sublime syntax system is fairly context free; it parses the structure of the code but it doesn't contain any real structural information about it.
So for example it can determine that getShots is a function or method because of the syntax that was used to define it, but it doesn't know what class it came from.
The code for the hover popup is available in Default/symbol.py (you can use PackageResourceViewer to examine it) and associates symbols under the cursor with other places that it's seen symbols with that name in other files in the project; it literally only knows the information that you see in the popup; places where things by that name are defined and places where things of that name are referenced.
So in one sense, the answer to your question is No; core sublime can't do that because it doesn't have enough code intelligence to be able to figure that sort of thing out; this is exacerbated by dynamic languages like JavaScript where things can theoretically change at runtime as well.
The primary reason for that is because Sublime is extensible enough to support literally every programming language instead of just focusing on one or two (as e.g. PhpStorm does), so it doesn't have the core code to determine the information required.
All that said, since Sublime is indeed extremely extensible, it's possible that external code that does specialize on a language could be leveraged by a package in order to provide the appropriate information.
Two examples of that are SublimeCodeIntel and LSP for example. I don't use either of them myself, so I don't know for sure how good a fit they might be in your workflow.
I highly recommend you shift to Visual Studio Code majorly because sublime is an editor whereas vs code is an IDE. Also, it has very great extension support for all languages. I would recommend you to use jshint which the most popular plugin for js code available for almost all popular editors and IDEs. But still if you want to go with Sublime I suggest you following plugins:
https://www.sitepoint.com/essential-sublime-text-javascript-plugins/
VS2012's resource designer doesn't seem to have a way to "expand" long strings of text/html.
I have to double-click each and every one line to expand it.
Knowing I have about 10,000 of these to do for this localization project, I'm going to go mad if I can't find a way to go from this:
http://i.imgur.com/TiKv5.jpg
...to this: http://i.imgur.com/p41bn.jpg
If there isn't, please suggest some alternate tool, app, or method that will help me keep my sanity.
Try the Visual Studio Power Productivity Tools for some help there. I know they really enhanced it for opening and collapsing the solution folders so it might help you.
At our company we wrote a small utility to extract these resources from Visual Studio to package in the excel format that our translation company uses. It didn't take much to do that in .NET and it will certainly make your life easier in the long run.
Turns out Microsoft also has a Resource Refactoring Tool that looks like it makes it easy to pull resources out of the code and resx files into other formats. I have not tried this personally (where I have used the Productivity Tools) but it is worth looking into this option.
I'm a long time Eclipse user trying to learn to Visual Studio. I know that Eclipse had Code Templates that would allow you to build classes with certain comments and formatting already added for a class.
For example:
Auto placing the copyright for the code at the top of the file
Who created the file
Predefined Comments,
etc...
Does Visual Studio 2005 have any functionality like this?
It depends. Visual Studio has a built-in code snippets manager that lets you do things like this to at least a degree (i.e., if you insert a code snippet, it'll be formatted as the snippet specifies, but if you write the same code manually, it won't). Also note that there are limitations on the languages with which you can use code snippets.
Outside of that, most of the major add-ins for VS (e.g., Visual Assist-X) provide their own ability to store and insert bits of code, formatted as you specify. Most of these provide at least some features missing from the built-in snippets manager such as working with other languages or being easier to access (along with quite a few other things -- IMO, VS borders on completely unusable without VA-X).
I would recommend looking at item and project templates in Visual Studio, which sound like what you're looking for. But, in your particular case (C++ development), it doesn't look like this is available to you.
The following MSDN article refers to VS templates, and mentions that for Visual C++ projects, that the template architecture isn't supported. Instead, there's information on creating custom wizards for your project and classes, which may give you the flexibility that you need. Sounds like it'll do what you want it to do, but it's much more work than it would be if you could use an item template for including basic comment structure for a default class file.
http://msdn.microsoft.com/en-us/library/6db0hwky%28VS.80%29.aspx
Ok, I've seen a few posts that mention a few other posts about not using SP wikis because they suck.
Since we are looking at doing our wiki in SP, I need to know why we shouldn't do it for a group of 6 automation-developers to document the steps in various automated processes and the changes that have to be made from time to time.
Here are some caveats I came across that will vanish if you use a wiki other than Sharepoint.
Sharepoint lets you create tons of separate wikis, but I'd recommend having one big wiki for everything. My company made a bunch of little wikis for each project/feature, but only admins can create the individual wikis, so if I want to write about something that isn't doesn't match one of the predefined categories, I have to find a manager to create the wiki first.
Secondly, if you use Sharepoint make sure everyone on your staff only uses IE, since Firefox doesn't support the WYSIWIG editor. This is a good thing for most wikis, but makes collaborating difficult in Sharepoint. Imagine editing auto-generated HTML in a tiny little box all day.
Third, try to write up your project documentation in the wiki and resist the temptation to upload Word docs to the Sharepoint library. No point in writing up all your docs twice and watching things get more and more out of sync.
Finally, image support in Sharepoint wikis is terrible. You have to add a file to a document library somewhere and type in the URL. My images were forever getting deleted because they don't seem to make much sense out of context.
I have a much more positive view of Microsoft's Sharepoint Wiki. In many ways it reminds me of FrontPage 98 -- and that was an unfairly maligned product.
The comment about using a list is misguided. Sharepoint Wikis ARE Sharepoint lists, in which each page is a list item with an HTML attachment.
It's true that you can't link into a page, but if the pages are short I don't see that as a problem. SP Wiki makes it very easy to have short pages.
You can manipulate the Wiki attributes from access 2008 if you wish, and you can add attributes to the wiki list items as desired. For example -- do you want categories? Just add them by editing the list. Want specific views? of list items. Create them too.
There's real genius in the way Microsoft built their Wiki framework atop Sharepoint lists -- which are undeniablly well done.
The TRUE drawback of Sharepoint Wiki was mentioned by famerchris. The approach to image management is surprisingly awful. It's such a serious problem that you should consider other Wikis for this reason alone.
There is a convoluted workaround that I use. It takes advantage of the superb Sharepoint support and image editing integrated with Windows Live Writer.
Create a SP blog that will hold the images that will be referenced in the wiki.
Use Windows Live Writer to post to the wiki-image-blog. Drop your image into WLW, resize it as needed, etc. If you like, use WLW to write your image associated wiki text first draft as well.
After you post to the Wiki, copy and paste image and text into the Wiki editor rich text field.
This takes suprisingly little time, far less than any other option I've read of. I admit, it is convoluted.
Other than the image problems I'm pleased and impressed with the product. If only Microsoft had thought harder about images ... if only ...
The default wiki included with Sharepoint doesn't support common wiki features well at all. There is no way to edit a single section of a page, and no way to link directly to a particular section on another page. The backend is in HTML so you lose the ability to edit in plaintext using simple syntax. The diff feature can't span multiple versions. Poor cross browser support of WYSIWYG editing. No way to auto-insert a table of contents...
There are, however, other wiki add-ins for Sharepoint which I can't categorically dismiss, for instance Confluence makes an add-in for Sharepoint. I haven't evaluated this software myself, and Confluence is somewhat expensive ($1,200 for 25 user license) although if you are already on Sharepoint I sense large corporate coffers :P. There also appear to be some free add-ins like CKS Enhanced Wiki but that appears to have a lot of the same problems mentioned above.
We run into this topic all the time, and the first question I have taken to asking people is "Why do you need a wiki"? Almost always the answers are things "ease of editing", "multiple contributors", and "Word is to heavyweight". Very rarely have we seen anyone ask for what I consider to be uniquely wiki-like features (special "magic" markup, fine grained version history showing changes, etc). Also, they usually want some kind of categorization of things, not just completely free-form pages.
In the SharePoint world these things should scream "list" at you if you've been working with the tool for a while. There is basically no particular reason to use a wiki for these knowledge base-style applications, especially since "ease of editing" usually directly conflicts with the idea of learning a special markup language for most user. Through a couple of rich-text columns in there, and you're all set. If you really don't like the built-in rich-text editor (yes the image uploading process is clunky and it doesn't work in Firefox), have someone in your organization go drop the 8 Benjamins and go get the RadEditor for SharePoint. It should pretty much handle those concerns.
Generally once we've gotten over the "but it needs to be a wiki" dogma, we've had pretty good customer reception to just using lists. In some cases, where a little more of a page templating facility was required we turned to using the WCM features of MOSS, which requires a little more up-front thought about templates, but also has a better out of the box experience for things like content snippets and image handling.
Because the default implementation is not a wiki, it is an HTML editor.
If you've used a wiki before you'll know the difference. Just look at "Your answer" at the bottom of this page to see the difference. You use markup in a wiki, which is relatively easy to read and edit. Formatted HTML completely obscures what is written.
My two cents worth as a wiki content creator and super-user, rather than an administrator or developer:
I am currently editing a document in Sharepoint Wiki as I type this, and it is by far the worst editor I have ever come across. To be precise, I'm using Sharepoint Foundation 2010 (previously known as WSS), editing pages using IE 9.
To sum up the problems I've faced: When creating wiki content you want to concentrate on the content and the wiki engine should be so easy to use as to be almost invisible. With Sharepoint that is not the case. I really struggle with the pseudo-WYSIWYG editor, having to fix frequent formatting problems.
I estimate that I'm about 15% less productive writing wiki content with Sharepoint than I am with ScrewTurn or Wikimedia because I have to deal with the formatting issues. If I spend a day writing wiki pages I would lose about an hour trying to fix formatting issues.
For background: I've created four internal wikis at our company - the first in Wikimedia, the wiki engine behind Wikipedia, the next two in ScrewTurn, and a final one in Sharepoint. In each wiki I've written about 50-100 pages.
In both ScrewTurn and Wikimedia the editor looks fairly primitive - a plain text editor that uses simple wiki mark-up codes for formatting. Each has a row of buttons that can apply mark-up codes for simple things like bold and italic formatting, and to create links, so beginners do not need to learn the mark-up codes by heart. While the editors look plain they turn out to be really simple to use, especially for fixing formatting problems.
Sharepoint Wiki, on the other hand, looks slick but is terrible for editing. Instead of using a plain text editor with wiki mark-up it has a WYSIWYG editor that looks much more sophisticated than other wiki editors. However it has personality, an evil one. It frequently adds blank lines or changes the colour of text. When I select text to format then go to the Markup Styles dropdown to format it, sometimes the act of selecting an item from the dropdown list deselects the selected text so the formatting applies to text at a random location. Inserting text copied from Word sometimes causes the editor to double or triple up on blank lines between paragraphs at other places on the page. There appears to be no easy way of creating a table, apart from writing HTML.
The biggest problem about the editor, however, is that you can't easily see what is going on behind the scenes so it's difficult to fix it. Yes, it's possible to edit the page's HTML but that really defeats the purpose of a wiki.
The overall impression I get as a user, is that this is alpha-level code that has been knocked up by a summer intern. I know Foundation is the free version so perhaps I get what we've paid for but I cannot believe a professional software company put out this product.
For a group of 6 people that will be making "every now and then" edits, the built-in wiki will be fine.
The Sharepoint Wiki is essentially a list of Static HTML Pages, with the only Wiki-feature being [[article]] links. No Templates, No Categories, nothing.
We ended up having a separate MediaWiki and only use the Sharepoint wiki for text-based content that does not need much layout.
Don't forget the Community Kit for Sharepoint - Enhanced Wiki Edition. This adds some features to the out of the box version.
Before the rant, here is my overall experience with SharePoint as a wiki.
It is a poorly implemented feature that failed becouse there was a fundemental lack of investigation into what current wiki environments provide. That is why it failed in it's editor and why it misses on points like: tagging, history comparison, and poorly generated html code.
You need to skip it and get something else that does the job better and link to it from SharePoint.
Having production experience with both products, I'd recommend ScrewTurn over SharePoint.
see edit history for rant
My company rolled out sharepoint recently, and I have to say my user experience was Very Bad. And I'm not just saying I was apprehensive to using it: I went in with an open mind and tried it, and many things just felt like they didn't really work right.
The reasons Luke mentioned more or less cover it.
Why wouldn't you consider using something else like Screwturn Wiki which Jeff donated to a short while ago? I haven't used Screwturn myself, but it is free and open source, and may be a faster lightweight solution for what you need.
We looked at Sharepoint for a department wiki a few months ago. Even though we're primarily an MS shop, we went with DokuWiki. Open-source, so easy to keep up to date, great plugins, and a file-based back end.
I would also temper the ratings of the OOB wiki and its lack of functionality with the technical level of the authors here.
I agree that the SP wiki might qualify in name only - certainly when compared to some more robust offerings - but remember as an admin - your primary success is determined by end user adoption. In short - for every feature that a wiki like Confluence adds, it also adds user education, syntax, etc.
While I would love SP wiki to have more "wiki-like" - there is a certain, undescribable satisfaction you can take when your CIO adds an entry in the company wiki - or you are recognized by a group of administrative assistants who find the new wiki "revolutionary".
In short - the built in functionality may be lacking to the jaded eyes of us tech professionals, but to the technologically naive, its pretty easy to train on, and can expose them to a technology they may have heard of but could never (before this) understand or imagine using.
I've played very briefly with SharePoint Wiki Plus. It's a third-party extension that adds features to the SharePoint Wiki. For serious wiki users then you probably need something more than the SharePoint provided Wiki - either via an extension or a dedicated Wiki product.
Maybe try http://wordtosharepoint.codeplex.com/ for migrating your Word content to SharePoint? It takes care of linking images and most other things.
Screwturn is wicked awesome - and it is C# / .Net.
Sharepoint 2010 is supposed to have better wiki features, and there is always the community kit of sharepoint.
If you are able to leave the Sharepoint Wiki behind - you could always head over to the http://www.wikimatrix.org to find the wiki that works for you.
I fully concur with the above (Keng). Whatever that thing is within SharePoint (currently using 2010), it is NOT a Wiki by a long shot.
I am implementing an automated documenting solution, where I extract config and other info (like perldoc markup) from source code and XML config files. It inserts the info in a set of DokuWIKI pages, complete with formatting markup (including tables). It comes out perfectly formatted and works with a couple of tens of lines of perl, includes internal links to manually edited static doc pages, and support for namespaces so I can have my information logically organised. There is no way I could do that in SharePoint (sigh - company direction)...
The best I can do is try to make DokuWIKI template resemble sort of the SharePoint site (to keep the look and feel similar) and link out of SharePoint. :-(