Forum Replies Created
- Posts
Thank you!
I was not aware that I could use the WShell Popup method, that indeed gives some nice extra runtime user input.
The PopupMenu object is the one I was looking for, thank you. Very useful.
I totally disagree. It’s like, “it would be cool if you could edit video files in EmEditor, please, I want to see this in the next release”.
The beauty of EmEditor is exactly that it sticks to the principle that it services plaintext files. If one needs rich text editing, there are thousands of freeware/commercial sofware that do exactly that.
I have been willing EmEditor to support more elaborate XML editing, and comma/tab delimited text file editing (in cell grid), as it seems to be related stuff, but I understand that it could be matter of personal subjective preference, and if Yutaka doesn’t see that EmEditor has special features for those special text file types, it’s his product after all.
— Pavils
EmEditor DOM is not exposed for other applications
I am not very competent in Windows C application programming, so my question might appear stupid… I was under impression that everything (well, almost) that user can do with EmEditor interface – is possible via macros. The plugins allow to add things like extra windows and extra controls on the existing window (like expand-collapse buttons of the outline plugin). The plugins seem to have ver integrated way of communication with base EmEditor. I am very surprised to hear that there could not be a plugin that sends a “mini macro command” to base EmEditor for execution, and gets a value in return. But what do I know, maybe that requires extensive reprogramming and extra memory load. I’d say that exposing the DOM would allow to stop doing duplicate work with supporting similar range of functions for macros and plugins.
Ok, I have learned how to do the trick.
It seems like the editor keeps the last assumed scripting language in memory, and rewriting the declaration, and even reopening the file does not help to redraw the colors.
However, if I copy the code, paste it in new document, and save it as ASP file, the editor changes it’s present assumed scripting language.
Here are the steps for repeating the bug:
1. Start new document (A), write the following code:
<\%
‘AAAA’
\%>
2. Start another new document (B)
3. Copy the code from document A to document B.
4. Save the document B as “test.asp”
At this point you should see the ‘AAAA’ in green.
5. Change the scripting language in declaration to JScript in document B. The syntax coloring does not change.
6. Save the document B. The syntax coloring does not change.
7. Close the document B, reopen it from “recently viewed files” list. The syntax coloring does not change.
8. Create new document C, copy the code from document B to document C (it’s not with JScript declaration). Save the document C. The syntax coloring is now updated.Whenever the editor has assumed the language, if I then open an ASP file, it is displayed with this assumed language coloring, not the one that could be detectable from the file declaration.
Besides that, there are many files that are used as includes in the main file, and those do not have “@” declaration. There should be at least hacky way (ie, keyword in comments) to tell the editor what is the scripting language. Or, the default language could be set up in options somewhere, or the language could be detected with more advanced algorythm.
Yes, I have reference to scripting language in the declaration:
However, when I went on to prepare you sample with code and screenshot, I’ve found that I can not repeat the behaviour – the file was displayed wrong when opened once, but when I did selectAll+copy+paste, it looked correct. When reopened, it was again correct. I need to find a stable, repeatable bug presentation.
Oh, cool, I didn’t know that doubleclick works as tag jump. Although having the tag underlined would be nice, the doubleclick is fine for me. I use OutputBar to display the C# compiler ouptut, where there are references to errors/warnings in the code.
