headers
April White | 2 Dec 2005 02:12
Picon
Favicon

Re: 4th stage of reprogramming job system

Neil Hodgson wrote:

>>- the buffer flags isDirty and useMonoFont has been encapsulated within
>>  a buffer variable and controlled by enum flags
>>    
>>
>   Grouping all these into a bit set makes it too easy to incorrectly
>set multiple states. ... Code that uses bitsets is also longer with extra boolean
>operators.
>  
>
I've reversed my changes.

>   The biggest problem ... is that ProcessExecute ... is now modifying the current buffer
>  
>
I've been considering this for a bit.  You are quite correct but I think 
that storing the name of the buffer within a job is not sufficient.  The 
job that contains the flag that must be queried in order to assign 
isBuilt would not exist by the time the IDM_FINISHEDEXECUTE code runs.

I've noticed that I am not deleteing the job object within 
ProcessExecute().  I would like to:
- add a variable exitstate to the job class
- return the job as a void * instead of the exitstate

This way the IDM_FINISHEDEXECUTE code can get the exit state and build 
flags.

I know I will not see your reply for some time, so I'll make a backup
(Continue reading)

Permalink | Reply | 3 comments |
headers
Neil Hodgson | 2 Dec 2005 13:43
Picon

Re: 4th stage of reprogramming job system

April White:

> I've noticed that I am not deleteing the job object within
> ProcessExecute().  I would like to:
> - add a variable exitstate to the job class
> - return the job as a void * instead of the exitstate
>
> This way the IDM_FINISHEDEXECUTE code can get the exit state and build
> flags.

   Wouldn't it be better if the IDM_FINISHEDEXECUTE was able to remove
the finished job object safely and query it for the file path and
status?

> I know I will not see your reply for some time, so I'll make a backup
> and try this anyway.

   There wasn't any code with this one so it didn't take so long to think.

   Neil
Permalink | Reply | 2 comments |
headers
April White | 3 Dec 2005 02:26
Picon
Favicon

Re: 4th stage of reprogramming job system

Neil Hodgson wrote:

>>I've noticed that I am not deleteing the job object within
>>ProcessExecute().  I would like to:
>>- add a variable exitstate to the job class
>>- return the job as a void * instead of the exitstate
>>
>>This way the IDM_FINISHEDEXECUTE code can get the exit state and build
>>flags.
>>    
>>
>   Wouldn't it be better if the IDM_FINISHEDEXECUTE was able to remove
>the finished job object safely and query it for the file path and
>status?
>
Hi Neil.

The SciTEWin::ProcessExecute() method currently pops a job off the 
queue, and I've modified IDM_FINISHEDEXECUTE to receive the job as a 
parameter via lparam.  I have not altered anything to store the buffer 
name so far, but the new code is working.

Oh, I am also planning on on having IDM_FINISHEDEXECUTE delete the job 
object.

I think that is what you are suggesting.  BTW, which is a 'better' means 
of assigning the buffer name to the job object:
1. adding a parameter to AddCommand(), or
2. utilizing CurrentBuffer() within AddCommand() - this absolutely 
depends on the buffer being unchanged between the time the AddCommand()
(Continue reading)

Permalink | Reply | 1 comment |
headers
Neil Hodgson | 3 Dec 2005 23:02
Picon

Re: 4th stage of reprogramming job system

April White:

> The SciTEWin::ProcessExecute() method currently pops a job off the
> queue, and I've modified IDM_FINISHEDEXECUTE to receive the job as a
> parameter via lparam.  I have not altered anything to store the buffer
> name so far, but the new code is working.
>
> Oh, I am also planning on on having IDM_FINISHEDEXECUTE delete the job
> object.

   I was thinking more like encapsulating this inside the JobQueue.
Sending void*s through SendMessage is sometimes a necessary evil but
it should be avoided when easy to do so. I suppose it is OK here.

> I think that is what you are suggesting.  BTW, which is a 'better' means
> of assigning the buffer name to the job object:
> 1. adding a parameter to AddCommand(), or
> 2. utilizing CurrentBuffer() within AddCommand() - this absolutely
> depends on the buffer being unchanged between the time the AddCommand()
> is called and the job object is created

   I can't see there being any possibility of switching buffers
between the start of the call to AddCommand and creating the job
object. The parameters dialog is modal when displayed for a command so
doesn't allow the user to switch buffers.

   Actions from the execute queue shouldn't affect the current buffer.
I suppose there could be an OnFinishedExecute Lua event that the user
could use to switch to a particular buffer such as the buffer
containing an error but there isn't any such event now.
(Continue reading)

Permalink | Reply | 0 comments |
headers
PCHC Support | 8 Dec 2005 08:38

Auto file versioning system?

Hello everyone,
 
I'm new to site and I was wondering if there was an add-on or some way that I could setup an "auto versioning" system for scite.. Example:
 
I start a new php script.  Add code and what not to it and then save it.  After saving it...right below the first <? line there's some information like...
Author: My name
Created: Date the file was first saved
modified: Date I last edited the file (none if a new file)
Version: Starts with 0.0.1 then increments everytime file is saved.
 
Thanks for any advice,

Mike
_______________________________________________
Scite-interest mailing list
Scite-interest <at> lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
Permalink | Reply | 2 comments |
headers
Piotr Fusik | 8 Dec 2005 13:58
Picon
Favicon

Re: Auto file versioning system?

> I'm new to site and I was wondering if there was an add-on or some way 
> that I could setup an "auto versioning" system for scite.. Example:
>  
> I start a new php script.  Add code and what not to it and then save 
> it.  After saving it...right below the first <? line there's some 
> information like...
> Author: My name
> Created: Date the file was first saved
> modified: Date I last edited the file (none if a new file)
> Version: Starts with 0.0.1 then increments everytime file is saved.

SciTE is designed to be a text editor and not IDE, with KISS rule in mind.
So the answer is: no, SciTE has no such feature.
However, this should be easy to do with a Lua script.

I think you probably need a version control system (such as CVS or SVN),
where you could easily store old file versions. Version control systems
support some "tags" by themselves to fill information such as who
modified the file, when, and what is the version number.

Piotr
Permalink | Reply | 1 comment |
headers
Kein-Hong Man | 8 Dec 2005 20:13
Picon

Re: Auto file versioning system?

Piotr Fusik wrote:
>> [snip]
>> I start a new php script.  Add code and what not to it and then save 
>> it.  After saving it...right below the first <? line there's some 
>> information like...
>> Author: My name
>> Created: Date the file was first saved
>> modified: Date I last edited the file (none if a new file)
>> Version: Starts with 0.0.1 then increments everytime file is saved.
> 
> SciTE is designed to be a text editor and not IDE, with KISS rule in mind.
> So the answer is: no, SciTE has no such feature.
> However, this should be easy to do with a Lua script.
> 
> I think you probably need a version control system (such as CVS or SVN),
> where you could easily store old file versions. Version control systems
> support some "tags" by themselves to fill information such as who
> modified the file, when, and what is the version number.

I agree with Piotr. A Lua script could be written to do that, but 
it is the wrong thing to do. Learning CVS or SVN is well worth the 
effort.

--

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
Permalink | Reply | 0 comments |
headers
spam trap | 9 Dec 2005 01:33

Re: Scite-interest Digest, Vol 31, Issue 4

Thank you Piotr and Kein-Hong for the information.  I will look at CVS and 
SVN.  Topic solved!

Mike
----- Original Message ----- 
From: <scite-interest-request <at> lyra.org>
To: <scite-interest <at> lyra.org>
Sent: Thursday, December 08, 2005 3:01 PM
Subject: Scite-interest Digest, Vol 31, Issue 4

> Send Scite-interest mailing list submissions to
> scite-interest <at> lyra.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.lyra.org/mailman/listinfo/scite-interest
> or, via email, send a message with subject or body 'help' to
> scite-interest-request <at> lyra.org
>
> You can reach the person managing the list at
> scite-interest-owner <at> lyra.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Scite-interest digest..."
>
>
> Today's Topics:
>
>   1. Auto file versioning system? (PCHC Support)
>   2. Re: Auto file versioning system? (Piotr Fusik)
>   3. Re: Auto file versioning system? (Kein-Hong Man)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 8 Dec 2005 02:38:28 -0500
> From: "PCHC Support" <support <at> pchelpcenter.org>
> Subject: [scite] Auto file versioning system?
> To: <scite-interest <at> lyra.org>
> Message-ID: <000f01c5fbca$617f85c0$6500a8c0 <at> home62209f388a>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello everyone,
>
> I'm new to site and I was wondering if there was an add-on or some way 
> that I could setup an "auto versioning" system for scite.. Example:
>
> I start a new php script.  Add code and what not to it and then save it. 
> After saving it...right below the first <? line there's some information 
> like...
> Author: My name
> Created: Date the file was first saved
> modified: Date I last edited the file (none if a new file)
> Version: Starts with 0.0.1 then increments everytime file is saved.
>
> Thanks for any advice,
>
> Mike
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> http://mailman.lyra.org/pipermail/scite-interest/attachments/20051208/f3a6ba22/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Thu, 08 Dec 2005 13:58:02 +0100
> From: Piotr Fusik <pfusik <at> op.pl>
> Subject: Re: [scite] Auto file versioning system?
> To: Discussion of the SciTE editor <scite-interest <at> lyra.org>
> Message-ID: <43982DDA.80104 <at> op.pl>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>> I'm new to site and I was wondering if there was an add-on or some way
>> that I could setup an "auto versioning" system for scite.. Example:
>>
>> I start a new php script.  Add code and what not to it and then save
>> it.  After saving it...right below the first <? line there's some
>> information like...
>> Author: My name
>> Created: Date the file was first saved
>> modified: Date I last edited the file (none if a new file)
>> Version: Starts with 0.0.1 then increments everytime file is saved.
>
> SciTE is designed to be a text editor and not IDE, with KISS rule in mind.
> So the answer is: no, SciTE has no such feature.
> However, this should be easy to do with a Lua script.
>
> I think you probably need a version control system (such as CVS or SVN),
> where you could easily store old file versions. Version control systems
> support some "tags" by themselves to fill information such as who
> modified the file, when, and what is the version number.
>
> Piotr
>
> ------------------------------
>
> Message: 3
> Date: Fri, 09 Dec 2005 03:13:58 +0800
> From: Kein-Hong Man <mkh <at> pl.jaring.my>
> Subject: Re: [scite] Auto file versioning system?
> To: Discussion of the SciTE editor <scite-interest <at> lyra.org>
> Message-ID: <439885F6.70301 <at> pl.jaring.my>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Piotr Fusik wrote:
>>> [snip]
>>> I start a new php script.  Add code and what not to it and then save
>>> it.  After saving it...right below the first <? line there's some
>>> information like...
>>> Author: My name
>>> Created: Date the file was first saved
>>> modified: Date I last edited the file (none if a new file)
>>> Version: Starts with 0.0.1 then increments everytime file is saved.
>>
>> SciTE is designed to be a text editor and not IDE, with KISS rule in 
>> mind.
>> So the answer is: no, SciTE has no such feature.
>> However, this should be easy to do with a Lua script.
>>
>> I think you probably need a version control system (such as CVS or SVN),
>> where you could easily store old file versions. Version control systems
>> support some "tags" by themselves to fill information such as who
>> modified the file, when, and what is the version number.
>
> I agree with Piotr. A Lua script could be written to do that, but
> it is the wrong thing to do. Learning CVS or SVN is well worth the
> effort.
>
> -- 
> Cheers,
> Kein-Hong Man (esq.)
> Kuala Lumpur, Malaysia
>
>
> ------------------------------
>
> _______________________________________________
> Scite-interest mailing list
> Scite-interest <at> lyra.org
> http://mailman.lyra.org/mailman/listinfo/scite-interest
>
>
> End of Scite-interest Digest, Vol 31, Issue 4
> *********************************************
>
>
Permalink | Reply | 5 comments |
headers
J44xm | 9 Dec 2005 07:30
Picon

Starting SciTE maximized and key combo to exit

I've tried searching around online, but I can't find the answer to this 
question: Is it possible to make SciTE start maximized, as opposed to a set 
window size and position, in Windows?

Also, can someone point me in the direction of setting an easy key combination 
to exit (Alt-X or Alt-Q is what I'm thinking, for the record)?

Many thanks.
Permalink | Reply | 3 comments |
headers
Piotr Fusik | 9 Dec 2005 12:04
Picon
Favicon

Re: Starting SciTE maximized and key combo to exit

> Also, can someone point me in the direction of setting an easy key combination 
> to exit (Alt-X or Alt-Q is what I'm thinking, for the record)?
> 
Alt-F4
Permalink | Reply | 0 comments |

Gmane