[TheXman]

I should add that Help|About shows v14.5.4. However the the file information in the EmEditor.exe file itself still says v14.5.3. I’m sure that Help|About is not getting its information from the file but from somewhere on the disk like the registry or AppData.

[TheXman]

You said you would try to keep them in sync. Just like 8.0.1 and 8.0.2, 8.0.3 is on the webpage but the executable is 8.03. I know it isn’t a big deal but it still isn’t right.

[TheXman]

You got much closer this time. :-) The version number in the executable’s resource header is not exactly the same as what is posted on your web page. The executable’s file version is 8.0.1 and the web page shows 8.01. It’s not a big deal but it does cause my app to think that there is a different version available on the web. :-)

[TheXman]

How about adding a “Save As…” toolbar button also? :-)

[TheXman]

Yutaka wrote:
In Command Prompt, you can use FOR statement. For example:

	for \%f in (*.ini) do emeditor.exe \%f

	

With all due respect, I’m aware of several workarounds. My question was whether you can will alleviate these workarounds by implementing a widely accepted syntax into the editor to open files using wildcards from the command line without workarounds.

Xavier

[TheXman]

wdscxsj wrote:
I think interpreting wildcard characters is usually the shell’s reponsibility.

What interprets wildcards is not the point of my post. The fact that one cannot open multiple files at once using wildcards from the command line is my point. I posted this as a Core Enhancement request back on 5/27/2007 @ 1:53 pm. It looks like part of the request was implemented (multiple file selection from the OpenFile dialog). I was just asking if the other part of the request could be implemented (multiple file selection using wildcards from the command line).

Let me give a brief example to elaborate. Let’s say that you have a folder that has multiple ini files in it such as the EmEditor application folder. Then let’s assume that you want to open and view all of those ini files. If from the command line you entered the syntax: “Emeditor *.ini”, you would receive an error message saying that “The specified path is invalid”. You would have assumed that the syntax would have opened all of the ini files in that folder. The only way to open all of the ini files in the folder from the command line, using Emeditor, would be to know and to list each ini file with the following syntax: “Emeditor inifile1 inifile2 inifile3 …”. This seems a bit cumbersome.

Xavier
:-D

[TheXman]

I apologize, I should have been more specific. I meant to be able to open multiple files using wildcards. i.e. *.ini

[TheXman]

Yutaka wrote:
I fixed most of relative/absolute path issues on beta 3. Please give a try!

Yes, the 2 types of portability tests that I reported earlier are working! Thanks! :-D I’ll continue testing other scenarios in order to help make it as bulletproof as possible. Keep up the good work!

[TheXman]

Thanks! Your hard work is greatly appreciated.

[TheXman]

I have installed EmEditor7 beta on a USB flash drive using the export function. In looking at the ini files after initial configuration, it looks as though all references to folders contain the drive letter. After testing the portability of the app by renaming the folder, all plugins were missing on the toolbar. I also tested the portability by making sure that the USB flash drive used a different drive letter. Of course I got the same result. I assume this is because the reference to them in the ini files are static and still pointing to the old folder structure. For portability, especially on a USB flash drive that may get a different drive letter when plugged in, any references to files and folders would need to be dynamic/relative based on the current drive letter. This would be true for at least the plugins, macros, templates, syntax files, and any other fiolders/files needed to support EmEditor’s funtionality. Open file histories and projects would probably a little more difficult to validate.

One way for this to work for files and folder that support the application, would be to make certain assumptions as to where the folders are relative to where the EmEditor.exe file that started the specific process resides. For instance, the macros folder would have to reside in a folder subordinate to the folder in which the EmEditor.exe file resides. The same would be true for plugins (which it already is). Currently, by default, syntax files and templates reside in the same folder as the application’s exe file. It would be nice if they could optionally reside in sub folders also.

It is very welcome that EmEditor v7 does not write any information to the registry, but it is not quite portable yet.

I hope I’ve communicated the issue effectively. If you need me to elaborate on anything, please ask.

Keep up the good work!

Xavier :-D

[TheXman]

Yutaka wrote:
I will probably release the beta 1 version tomorrow. :-)

How does one obtain beta versions? Is there a formal beta testing forum in which one can post bugs?

[TheXman]

Don’t tease us, just release it. Using pseudo-specific terms like “…will be released soon” tends too frustrate people if the release is not imminent.

Impatiently waiting for a stable v7 release,
Xavier
:-D

[TheXman]

I’m sure you’re trying to get the finishing touches on the next release as soon as possible. Are there any betas available to test? I’m dying to get a portable version of EmEditor so I can finally get to the point where I no longer have to carry and know 2 different text editors. A purely portable version would work for me. U3 would be nice but not necessary since portable apps can be run from U3.

Xavier

[TheXman]

I stayed away from the U3 technology for quite a while. I recently starting using it and I actually like it. Although, most of the apps on my USB drive are portable apps not u3 apps. However, I do have a couple of U3 apps that I now use everyday. RoboForm2Go is one of them. Since U3 seems to be rather stable now, I plan to add more U3 apps as ones that I like become available. Since there is a way to create U3 shortcuts to regular portable apps, it really doesn’t matter whether U3 version exists initially. Creating U3 shortcuts to portable apps is still a bit of a PowerUser function. It’s not something that the average USB Flash Drive user would/could easily do. Therefore, I’m sure a U3 version would become very popular. At this time, there only seems to be one other real competitor that has a full-fledged U3 compatible version available.

Xavier

[TheXman]

By the way, if you need a beta tester for the portable enhancement, I would be happy to help. :)

Xavier

[TheXman]

That is great news! I am impatiently awaiting the release that includes portability.

Thanks.

[Author]

Posts