I am not particularly happy with using Edit or RichEdit control
for console I/O but these were the only two (almost)
ready-to-use controls in Delphi. I may have to rethink this
although I would be a bit reluctant doing it from scratch...
Post by RS* It somewhat flickers (harmless, but makes it look a bit 'fragile'...)
Delphi controls are notorious for this kind of extra refreshing. I
will likely end up abandoning REC and replace it with a custom
one.
Post by RS* Is there no other way than to use Rich Edit Control? The console could
be enhanced quite a bit if the command prompt shortcuts like
TAB for file name completion or the Arrows for walking through
the command history or CTRL-C for cancel worked. Also, the
oddities with CTRL-L and other shortcuts wouldn't arise.
I tried to generate CTRL_C_EVENT in response to Ctrl+C but it
does not work. There may be a way around with some effort. The
rest again means that a different control (with different
custom programmed responses) should be used or else a custom
event handler implementing alternative responses and
suppressing the unwanted ones should be implemented. This means
custom programming or finding a third party control that
already does that (I am not aware of any)...
Post by RS* I've tried to run a cygwin shell in the Console but the text is
somehow garbled (also connected to REC?). What would look like
--------------------------------------------
$ pwd
/home/schlcht
$
--------------------------------------------
--------------------------------------------
#27]0;~#07
$ pwd
pwd
/home/schlcht
#27]0;~#07
$
#27]0;~#07
$
in WinEdt's console (above, I've replaced '#27' and '#07' for
the actual control characters ASCII 27 and 07).
Ah: VT100 ESC sequences! It's been a long time since I have
last worked on a VT100-compatible terminal but the above code
suggests that cygwin requires VT100-compatible control since it
obviously sends ESC sequences to the terminal. REC is, of
course, not VT100 compatible (neither is any standard Windows
Control).
I am not using cygwin but I would suggest that you check if it
can be started with some switch to suppress echo or at least
suppress VT100 ESC sequences. For example, Windows Command
Prompt should be started with
cmd.exe /Q
to avoid double-echo in WinEdt's Console.
How does cygwin shell perform in standard Windows Console (or
does it start its own Window)?
Post by RS* Could `Copy to Clipboard' not be made to work while the application is
still running? Also, text can be selected, but the selection
immediately disappears again, so you cannot copy manually,
either.
Something could be done about this I suppose. But it again
comes to the general suitability of REC for this purpose.
Post by RS* 'Terminate Application' only terminates the application on the second
click.
This was a bug: fixed.
Post by RS* When switching back to WinEdt from another application, the focus is
always in the editing window, even it was in the console before switching.
Something can be done about this. I'll check into it.
Post by RS* Something like 'more' would be very nice, ie., to only show one page
of text at a time, and wait for the user to press a key to show
the next bit.
I will likely abandon REC and make a custom one. We can add
more fancy functionality to it later.
Actually, after a few days searching msdn for documentation I
did discover a few things. I can now generate CTRL_C and
CTRL_BREAK events but it is very complicated: WinEdt has to
temporarily attach to the "invisible" console, declare custom
ctrl event handlers (to prevent Windows from killing it as
well) then it can generate the event and free the console. To
make things worse, the kernel32 API function that can attach a
console is new and it is only available on XP and Vista. WinEdt
dynamically loads this function (if it is there). Thus WinEdt
will work on older Windows but CTRL+C (Break) in its console
will be ignored unless this function can be loaded.
I still have to decipher a few mysteries regarding sync input/
output using pipes and then I should be able to emulate
standard console behavior with or without (optional) echo... I
don't know about VT100 output (as used by cygwin), though:-)
Post by RSIn all, the Console is marvelous but I think there's room for
improvement.
I knew that I am in for a lot of trouble when I decided to try
a two way console. Alternative would be a readonly console
output and a 1-line simple edit control for input which you'll
find in most console-hosting GUI applications (often only one
way output is implemented).
Anyway, things can be changed and improved but it will take
some work and thus some time to do it right...
Post by RS- WinEdt Macro engine was subject to substantial changes
Now that made me tremble but ...
The users should not notice any difference except for
improved macro execution speed and performance.
... I can confirm this up to now.
Good. It really had to be done as there was no more room for
any new macro functions and crashing during nested macros
execution was imminent -- I already knew how to reproduce it
and it was just a matter of time before you stumbled upon it,
too!
Post by RS- Tree and Gather interface now allows some extended processing
and specifications in order to include more useful information
EXLINELIMIT=16
CAPTION="%?: %!?"
Could you elaborate a bit on how this miracle works
(syntax-wise)?
I'll explain when I start documenting it. It is really a
semi-hard-coded thing (suitable for bib files or data bases
using identical format) with a few options regarding which
fields to expand and in what order... Gather control at the
bottom looked a bit "empty" and it is definitely nice to have
expanded bib data there. I am not so sure for Tree or Popup...
Post by RS===========================
Here's another feature that I've found in Word and would be
nice to have: when CTRL-clicking, the complete sentence is
selected. Of course, selecting a sentence can easily be done
with a macro, so I guess my feature request is to allow
configuration of the CTRL-click (and SHIFT and ALT, while we're
at it...) event. Possible? Already available?
I can introduce an event handler for qualified clicks. A macro
can check which keys are down and decide what to do. SetOK can
be used to tell WinEdt whether the event had been handled or a
default response is required... I'll do this as soon as the
console functionality is settled... It will take some planning
but advanced users may be able to take advantage of such
functionality and customize WinEdt beyond the defaults...
Best regards,
alex