dcplusplus-devel — Developer's list

Re: [dcplusplus-devel] adchpp patch: unicode for lua

[<bla...@ar...>]

> > The slnunicode libary is much bigger and adds the table "unicode.utf8"
> which is similar to the string libary.
> > When one replaces for example str:match(...) with
> unicode.utf8.cbb_match(msg, ...) it should do the same as before and work=
s
> also for utf8. (i did a mistake and renamed match to cbb_match)
> > I think it should be used for simple hubcommands like +reg nick or for
> things like bad word filters.
> Are you the author of the library? Or how did you make a mistake? Did you
> change the library?

i am not the author but i changed the name of some functions in the libary =
because i got
"redefined" compiler error in all.c.  these functions where already defined=
 in the string libary of lua.
i used replace of an editor and replaced also the name of the lua functions=
 "match" and "gmatch" in the table  "unicode" which is not necessary, that =
was the mistake.

Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT F=DCR ALLE NEUEINSTEIGER
Jetzt bei Arcor: g=FCnstig und schnell mit DSL - das All-Inclusive-Paket
f=FCr clevere Doppel-Sparer, nur  29,95 =80  inkl. DSL- und ISDN-Grundgeb=
=FChr!
http://www.arcor.de/rd/emf-dsl-2

Re: [dcplusplus-devel] adchpp patch: unicode for lua

[Jacek S. <arn...@gm...>]

> string.subutf8(string, start[,end]) substrings, UTF-8 aware 
> pos, char = string.nextutf8(string, orig_pos) returns the char at orig_pos and the next char's position in pos. 
> for i, char in str:nextutf8(orig_pos) iterates through the string, starting at orig_pos. 
> pos = string.seekutf8(string, orig_pos, n) returns the position orig_pos, N characters forward (or backwards, if N negative). 
> char = string.utf8char(code) returns the char the code of which is code. 
> code = string.utf8code(char) returns the code of char (UTF-8 character). 
> len = string.lenutf8(string) returns the length of string in UTF-8 characters.
> 
> and can be used when one has something exactly to count (for example for checking the length of nicks, counting words and chars of chats)
these seem to be of limited use since they treat utf-8 as a special case.

> The slnunicode libary is much bigger and adds the table "unicode.utf8" which is similar to the string libary.
> When one replaces for example str:match(...) with unicode.utf8.cbb_match(msg, ...) it should do the same as before and works also for utf8. (i did a mistake and renamed match to cbb_match)
> I think it should be used for simple hubcommands like +reg nick or for things like bad word filters.
Are you the author of the library? Or how did you make a mistake? Did you change the library?

> The first libary is maybe optional when one uses slnunicode.
Well, it seems easier to maintain just one library instead of two, so if the bigger library contains
the functionality of the smaller one, I see no point in adding the small one...

/J

Re: [dcplusplus-devel] adchpp patch: unicode for lua

[<bla...@ar...>]

The first libary is smaller and extends the standard string libary with:

string.subutf8(string, start[,end]) substrings, UTF-8 aware=20
pos, char =3D string.nextutf8(string, orig_pos) returns the char at orig_po=
s and the next char's position in pos.=20
for i, char in str:nextutf8(orig_pos) iterates through the string, starting=
 at orig_pos.=20
pos =3D string.seekutf8(string, orig_pos, n) returns the position orig_pos,=
 N characters forward (or backwards, if N negative).=20
char =3D string.utf8char(code) returns the char the code of which is code.=
=20
code =3D string.utf8code(char) returns the code of char (UTF-8 character).=
=20
len =3D string.lenutf8(string) returns the length of string in UTF-8 charac=
ters.

and can be used when one has something exactly to count (for example for ch=
ecking the length of nicks, counting words and chars of chats)

The slnunicode libary is much bigger and adds the table "unicode.utf8" whic=
h is similar to the string libary.
When one replaces for example str:match(...) with unicode.utf8.cbb_match(ms=
g, ...) it should do the same as before and works also for utf8. (i did a m=
istake and renamed match to cbb_match)
I think it should be used for simple hubcommands like +reg nick or for thin=
gs like bad word filters.

The first libary is maybe optional when one uses slnunicode.

> Why two libraries? when / how are these used?
>=20
> /J
>=20
> bla...@ar... wrote:
> > Hi=20
> >=20
> > this patch adds 2 unicode libaries to lua. The libaries can be found
> here:
> >=20
> > http://luaforge.net/projects/sln/
> > http://lua-users.org/wiki/ValidateUnicodeString
> >=20
> > I added the hubcommand "+slnunicode" to access.lua which executes the t=
est
> script of slnunicode.
> >=20

>=20

Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT F=DCR ALLE NEUEINSTEIGER
Jetzt bei Arcor: g=FCnstig und schnell mit DSL - das All-Inclusive-Paket
f=FCr clevere Doppel-Sparer, nur  29,95 =80  inkl. DSL- und ISDN-Grundgeb=
=FChr!
http://www.arcor.de/rd/emf-dsl-2

Re: [dcplusplus-devel] adchpp patch: unicode for lua

[Jacek S. <arn...@gm...>]

Why two libraries? when / how are these used?

/J

bla...@ar... wrote:
> Hi 
> 
> this patch adds 2 unicode libaries to lua. The libaries can be found here:
> 
> http://luaforge.net/projects/sln/
> http://lua-users.org/wiki/ValidateUnicodeString
> 
> I added the hubcommand "+slnunicode" to access.lua which executes the test script of slnunicode.
> 

Re: [dcplusplus-devel] patch: toolbar tooltips

[Jacek S. <arn...@gm...>]

ah, yeah, sounds like a reasonable way to do it =)

/J

poy wrote:
> played with some styles to have Windows (Common Controls >= 5.81) handle
> toolbar tooltips automagically. :)
> 
> related MSDN doc:
> BTNS_SHOWTEXT
> Version 5.81. Specifies that button text should be displayed. All
> buttons can have text, but only those buttons with the BTNS_SHOWTEXT
> button style will display it. This button style must be used with the
> TBSTYLE_LIST style and the TBSTYLE_EX_MIXEDBUTTONS extended style. If
> you set text for buttons that do not have the BTNS_SHOWTEXT style, the
> toolbar control will automatically display it as a ToolTip when the
> cursor hovers over the button. This feature allows your application to
> avoid handling the TBN_GETINFOTIP notification for the toolbar.
> 
> poy

[dcplusplus-devel] patch: toolbar tooltips

[poy <po...@12...>]

played with some styles to have Windows (Common Controls >= 5.81) handle 
toolbar tooltips automagically. :)

related MSDN doc:
BTNS_SHOWTEXT
Version 5.81. Specifies that button text should be displayed. All buttons 
can have text, but only those buttons with the BTNS_SHOWTEXT button style 
will display it. This button style must be used with the TBSTYLE_LIST style 
and the TBSTYLE_EX_MIXEDBUTTONS extended style. If you set text for buttons 
that do not have the BTNS_SHOWTEXT style, the toolbar control will 
automatically display it as a ToolTip when the cursor hovers over the 
button. This feature allows your application to avoid handling the 
TBN_GETINFOTIP notification for the toolbar.

poy 

Re: [dcplusplus-devel] patch: close tabs with the mid mouse button

[poy <po...@12...>]

yes, makes sense. so here is the same patch with no added bool.

poy

----- Original Message ----- 
From: "Jacek Sieka" <arn...@gm...>
To: "poy" <po...@12...>; "Patches & development discussion" 
<dcp...@li...>
Sent: Monday, December 03, 2007 9:43 AM
Subject: Re: [dcplusplus-devel] patch: close tabs with the mid mouse button


>A bool in the seed would be more in line with the rest of smartwin...on the 
>other hand, I don't
> think there's need for a bool at all...tabview is a high-level widget so 
> some intelligence would be
> expected (for example, the context menu isn't optional either).
>
> /J
>
> poy wrote:
>> as in most apps with tabs; pretty handy since there's no X button
>> anymore...
>> did it with an added bool in WidgetTabView::create.
>>
>> poy
>
> 

Re: [dcplusplus-devel] patch: close tabs with the mid mouse button

[Jacek S. <arn...@gm...>]

A bool in the seed would be more in line with the rest of smartwin...on the other hand, I don't
think there's need for a bool at all...tabview is a high-level widget so some intelligence would be
expected (for example, the context menu isn't optional either).

/J

poy wrote:
> as in most apps with tabs; pretty handy since there's no X button
> anymore...
> did it with an added bool in WidgetTabView::create.
> 
> poy

Re: [dcplusplus-devel] patch: tooltips on tabs

[poy <po...@12...>]

yes this looks like a much better way.
i've tried the attached patch (add TCS_TOOLTIPS to the tabs style and catch 
TTN_GETDISPINFO) but TTN_GETDISPINFO is never received apparently. i don't 
know what's missing...

poy

----- Original Message ----- 
From: "Jacek Sieka" <arn...@gm...>
To: "poy" <po...@12...>; "Patches & development discussion" 
<dcp...@li...>
Sent: Saturday, December 01, 2007 8:32 PM
Subject: Re: [dcplusplus-devel] patch: tooltips on tabs


> http://msdn2.microsoft.com/en-us/library/bb760550.aspx#tc_tooltips
> better use those
>
> poy wrote:
>> tooltips on tabs, added using the onMouseMove event as in the WTL
>> version. it was actually quite easier than i would have thought it would
>> be. :)
>> might conflict with my previous patch about tab closing on mid mouse
>> button click.
>>
>> poy
>>
>
> 

Re: [dcplusplus-devel] patch: tooltips on tabs

[Jacek S. <arn...@gm...>]

http://msdn2.microsoft.com/en-us/library/bb760550.aspx#tc_tooltips
better use those

poy wrote:
> tooltips on tabs, added using the onMouseMove event as in the WTL
> version. it was actually quite easier than i would have thought it would
> be. :)
> might conflict with my previous patch about tab closing on mid mouse
> button click.
> 
> poy
> 

[dcplusplus-devel] patch: tooltips on tabs

[poy <po...@12...>]

tooltips on tabs, added using the onMouseMove event as in the WTL version. 
it was actually quite easier than i would have thought it would be. :)
might conflict with my previous patch about tab closing on mid mouse button 
click.

poy 

Re: [dcplusplus-devel] Idea of PING extension for hublist pingers

[Eugen <pi...@de...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1252"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
If they're added to the existing INF, then all clients get the info
which is useless bandwidth usage.<br>
If the client has the PING value in the SU field, then the hub could
add these extra fields to it's <br>
INF command.<br>
If so, it means that these fields are added to BASE ? or just
client-based advertising ?<br>
It's a feature that both hub and client can support, its not c-c
related so my opinion is that <br>
it's supposed to be advertised in the initial SUP string...<br>
A minor correction : <br>
removing "HU - This information is about the hub"<br>
since its deprecated in latest ADC specs.<br>
<br>
<br>
<br>
Jacek Sieka wrote:
<blockquote cite="mid:475...@gm..." type="cite">
  <pre wrap="">Technically, these could be added to the existing ADC INF so that clients can detect them when
logging in...and then possibly have an additional flag in the client INF which says "I'm a pinger"...

/J

Eugen wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">=== PING - Pinger extension
This extension can be supported by both clients and hubs, and when 
present, if hub
supports it, it must send additional information to the client ( 
otherwise normal
base client)

When the client supporting the PING command connects, the hub must send its
normal INF along with the following added fields ( none mandatory, if 
not present,
it means hub has no restrictions in that matter ):

HH - Hub Host address ( DNS or IP )
WS - Hub Website
OW - Hub Owner name
UC - Current User count
SS - Total share size
SF - Total files shared
MS - Minimum share required to enter hub ( bytes )
XS - Maximum share for entering hub ( bytes )
ML - Minimum slots required to enter hub
XL - Maximum slots for entering hub
MU - Minimum hubs connected where clients can be users
MR - Minimum hubs connected where client can be registered
MO - Minimum hubs connected where client can be operators
XU - Maximum hubs connected where clients can be users
XR - Maximum hubs connected where client can be registered
XO - Maximum hubs connected where client can be operators
MC - Maximum possible clients ( users ) who can connect

Inherited fields from BASE:
NI - Hub Name
DE - Hub Topic
VE- Hub software version
HU - This information is about the hub




The hub may decide to disconnect pinger after all information is sent, 
or continue
to send the user list as for a normal user ( move to NORMAL state ).

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
<a class="moz-txt-link-freetext" href="http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4">http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4</a>
_______________________________________________
dcplusplus-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dcp...@li...">dcp...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel">https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
<a class="moz-txt-link-freetext" href="http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4">http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4</a>
_______________________________________________
dcplusplus-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dcp...@li...">dcp...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel">https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel</a>

  </pre>
</blockquote>
<br>
</body>
</html>

Re: [dcplusplus-devel] Idea of PING extension for hublist pingers

[Jacek S. <arn...@gm...>]

Technically, these could be added to the existing ADC INF so that clients can detect them when
logging in...and then possibly have an additional flag in the client INF which says "I'm a pinger"...

/J

Eugen wrote:
> === PING - Pinger extension
> This extension can be supported by both clients and hubs, and when 
> present, if hub
> supports it, it must send additional information to the client ( 
> otherwise normal
> base client)
> 
> When the client supporting the PING command connects, the hub must send its
> normal INF along with the following added fields ( none mandatory, if 
> not present,
> it means hub has no restrictions in that matter ):
> 
> HH - Hub Host address ( DNS or IP )
> WS - Hub Website
> OW - Hub Owner name
> UC - Current User count
> SS - Total share size
> SF - Total files shared
> MS - Minimum share required to enter hub ( bytes )
> XS - Maximum share for entering hub ( bytes )
> ML - Minimum slots required to enter hub
> XL - Maximum slots for entering hub
> MU - Minimum hubs connected where clients can be users
> MR - Minimum hubs connected where client can be registered
> MO - Minimum hubs connected where client can be operators
> XU - Maximum hubs connected where clients can be users
> XR - Maximum hubs connected where client can be registered
> XO - Maximum hubs connected where client can be operators
> MC - Maximum possible clients ( users ) who can connect
> 
> Inherited fields from BASE:
> NI - Hub Name
> DE - Hub Topic
> VE- Hub software version
> HU - This information is about the hub
> 
> 
> 
> 
> The hub may decide to disconnect pinger after all information is sent, 
> or continue
> to send the user list as for a normal user ( move to NORMAL state ).
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
> 

[dcplusplus-devel] patch: close tabs with the mid mouse button

[poy <po...@12...>]

as in most apps with tabs; pretty handy since there's no X button anymore...
did it with an added bool in WidgetTabView::create.

poy

[dcplusplus-devel] Idea of PING extension for hublist pingers

[Eugen <pi...@de...>]

=== PING - Pinger extension
This extension can be supported by both clients and hubs, and when 
present, if hub
supports it, it must send additional information to the client ( 
otherwise normal
base client)

When the client supporting the PING command connects, the hub must send its
normal INF along with the following added fields ( none mandatory, if 
not present,
it means hub has no restrictions in that matter ):

HH - Hub Host address ( DNS or IP )
WS - Hub Website
OW - Hub Owner name
UC - Current User count
SS - Total share size
SF - Total files shared
MS - Minimum share required to enter hub ( bytes )
XS - Maximum share for entering hub ( bytes )
ML - Minimum slots required to enter hub
XL - Maximum slots for entering hub
MU - Minimum hubs connected where clients can be users
MR - Minimum hubs connected where client can be registered
MO - Minimum hubs connected where client can be operators
XU - Maximum hubs connected where clients can be users
XR - Maximum hubs connected where client can be registered
XO - Maximum hubs connected where client can be operators
MC - Maximum possible clients ( users ) who can connect

Inherited fields from BASE:
NI - Hub Name
DE - Hub Topic
VE- Hub software version
HU - This information is about the hub




The hub may decide to disconnect pinger after all information is sent, 
or continue
to send the user list as for a normal user ( move to NORMAL state ).

[dcplusplus-devel] XSD and ADC

[Jacek S. <arn...@gm...>]

Hi,

erm, is there anyone on the list that feels confident with XSD that could tell me if the xsd in the
ADC spec (http://dcplusplus.sf.net/ADC.html) makes sense?

Regards,
Jacek

Re: [dcplusplus-devel] catching the enter key

[Jacek S. <arn...@gm...>]

Fine by me...

/J

poy wrote:
> i did it all in MDIChildFrame, with the same kind of way the
> backgroundcolor message is added to every widget.
> the patch includes fixes to PublicHubsFrame to make the filter work.
> 
> poy
> 

Re: [dcplusplus-devel] patch: update the main window title

[Jacek S. <arn...@gm...>]

ok. technically, add and addwidget could now be merged (they were split to move most of the
implementation to the cpp file...)

committing in any case...

/J

poy wrote:
> ok, as i thought. so here is the same patch, with the tab control that
> can only be used with WidgetChildWindow.
> 
> poy
> 

Re: [dcplusplus-devel] catching the enter key

[poy <po...@12...>]

i did it all in MDIChildFrame, with the same kind of way the backgroundcolor 
message is added to every widget.
the patch includes fixes to PublicHubsFrame to make the filter work.

poy

----- Original Message ----- 
From: "Jacek Sieka" <arn...@gm...>
To: "poy" <po...@12...>; "Patches & development discussion" 
<dcp...@li...>
Sent: Monday, November 26, 2007 10:34 PM
Subject: Re: [dcplusplus-devel] catching the enter key


> Hm, maybe winutil makes sense in this case since this is only needed if 
> IsDialogMessage is called
> and it's dc++ that decides to call isdialogmessage...
>
> /J
>
> poy wrote:
>> the "pressing enter in search wasn't working" issue was solved by adding 
>> the
>> following in answer to WM_GETDLGCODE in SearchFrame:
>> static HRESULT allKeys(WPARAM wParam, LPARAM) {
>>  if(wParam != VK_TAB)
>>   return DLGC_WANTMESSAGE;
>>  return 0;
>> }
>>
>> now there are several other parts of DC++ where such a thing would be
>> needed, eg in many list views, or the public hubs filter, pressing enter
>> isn't working.
>> so i was wondering wether i just copy-paste that everywhere i need it, or
>> should it rather be somewhere in smartwin?
>> or have the function in a place like WinUtil so that any class can have
>> access to it, thanks to tr1::bind. :)
>>
>> poy
>
> 

Re: [dcplusplus-devel] patch: update the main window title

[poy <po...@12...>]

ok, as i thought. so here is the same patch, with the tab control that can 
only be used with WidgetChildWindow.

poy

----- Original Message ----- 
From: "Jacek Sieka" <arn...@gm...>
To: "poy" <po...@12...>; "Patches & development discussion" 
<dcp...@li...>
Sent: Monday, November 26, 2007 10:30 PM
Subject: Re: [dcplusplus-devel] patch: update the main window title


> Well, that cast is not safe (because someone could call addWidget with a 
> window type different from
> WidgetWindow...a reasonable solution would be to make addWidget take a 
> WidgetChildWindow pointer
> instead and then change TabInfo to keep that pointer around...removes the 
> need for that template
> function in WidgetTabView even if it's slightly less flexible (since no 
> other widget types may be
> added), but I think it's worth it - the tab view is meant to hold child 
> windows...
>
> /J
>
> poy wrote:
>> update the main window title when the active child frame changes.
>> i added an event called onTitleChanged in WidgetTabView, not using any
>> dispatcher struct but simply with a callback function.
>> also, i'm not sure about that static_cast from Widget* to WidgetWindow*,
>> but it works fine here...
>>
>> poy
>
> 

Re: [dcplusplus-devel] patch: always focus the message box in chat frames

[Jacek S. <arn...@gm...>]

Ok.


poy wrote:
> at the moment, when a tab is selected, DC++ always gives the focus back
> to the widget of this tab that had the focus before the tab lost focus
> (hmm, hope it's understandable).
> 
> however, in some tabs like hubs and private messages, the focus should
> always be given to the message box, as it used to be in the WTL version.
> this little patch fixes it by adding a bool alwaysSameFocus in
> MDIChildFrame.
> 

Re: [dcplusplus-devel] AutoSearch reloaded...

[Jacek S. <arn...@gm...>]

itinerants wrote:
> Having added ...
>     fire(QueueManagerListener::AutoSearchingFor(), qi->getTarget());
> And logged and analysed what's going on with autoSearching, perhaps now is
> the time for an improvement?
> 
> Firstly, there is the problem of the 30 items - if nothing is found, and the
> "queue of 30" isn't full, autosearching simply stops. That's just a bug -
> it's happened to me and the only answer is to quit and relaunch the app,
> something I'm loathe to do when I've waiting 24 hours to get onto a given
> "difficult" download.
Yes, that's a bug if it happens...

> Even aside from that, the fact that a new candidate is found *randomly*
> means that, theoretically, there may be items that you *never* search for -
> they simply don't get randomly picked. Whilst I've never seen that happen
> (which might be hard seeing as how I'd have to, by definition, wait
> forever), I HAVE seen the same file searched for 3 times before a given file
> *did* get searched for.
Random to avoid searching for the same file from a rar-set or album or whatever since the file list
is downloaded on match catching those files anyway...

> However, going further, seeing that quite a lot seems to be happening at the
> moment, I'd propose one of the following 2 improvements to the algorithm...
> 
> 1) The pretty easy one...
> A) Remove the 30 limit entirely, letting the "recent" list get as large as
> it likes.
> B) When "findAutoSearch" fails to return a search candidate, empty the
> "recents" list. Next time around it'll start with a clean sheet. This easily
> fixes both problems listed above. I've implemented this and it works just
> dandy.
Which potentially could use a lot of memory for a large queue (100000 files)...but then again, the
queue itself will at that point use a lot of memory so maybe it's not so bad...

> 2) The harder, but "better" one...
> Build a list of everything that's eligible.
> Order this list, using...
>     Priority (user nominated it, let it mean something here as well)
>     Number of existing sources (I've waited hours for it to pick something
> with 0, yes zero, sources, whilst it gaily autosearched for things I had 60
> sources for already)
> Crunch through the list.
> When the list is empty, go to step 1
Won't work for large queues (recreating and ordering the list would be pretty costly...)

3)
Use a mark & sweep kind of algorithm and mark each item with a flag (since the QueueItem already
carries a flag field)...when all candidates are flagged, unflag all and restart...this would be
pretty cheap computationally and solve the 3-in-a-row and max-30 problems since all files will be
searched for before restarting...missing would be weight-by-priority, but that could maybe be solved
as well (for example unmark only highest first time, then highest+high, then highest+high+normal etc
)...


Now all that's missing is a patch =)

/J

Re: [dcplusplus-devel] catching the enter key

[Jacek S. <arn...@gm...>]

Hm, maybe winutil makes sense in this case since this is only needed if IsDialogMessage is called
and it's dc++ that decides to call isdialogmessage...

/J

poy wrote:
> the "pressing enter in search wasn't working" issue was solved by adding the 
> following in answer to WM_GETDLGCODE in SearchFrame:
> static HRESULT allKeys(WPARAM wParam, LPARAM) {
>  if(wParam != VK_TAB)
>   return DLGC_WANTMESSAGE;
>  return 0;
> }
> 
> now there are several other parts of DC++ where such a thing would be 
> needed, eg in many list views, or the public hubs filter, pressing enter 
> isn't working.
> so i was wondering wether i just copy-paste that everywhere i need it, or 
> should it rather be somewhere in smartwin?
> or have the function in a place like WinUtil so that any class can have 
> access to it, thanks to tr1::bind. :)
> 
> poy 

Re: [dcplusplus-devel] patch: update the main window title

[Jacek S. <arn...@gm...>]

Well, that cast is not safe (because someone could call addWidget with a window type different from
WidgetWindow...a reasonable solution would be to make addWidget take a WidgetChildWindow pointer
instead and then change TabInfo to keep that pointer around...removes the need for that template
function in WidgetTabView even if it's slightly less flexible (since no other widget types may be
added), but I think it's worth it - the tab view is meant to hold child windows...

/J

poy wrote:
> update the main window title when the active child frame changes.
> i added an event called onTitleChanged in WidgetTabView, not using any
> dispatcher struct but simply with a callback function.
> also, i'm not sure about that static_cast from Widget* to WidgetWindow*,
> but it works fine here...
> 
> poy

Re: [dcplusplus-devel] ADC typeing notification

[Jan T. <jan...@gm...>]

> I generally agree that this should go as a separate message - MSG is for sending text to the user,
> no use sending this kind of stuff as text (it would get logged, it couldn't be detected
> automagically etc etc)...
> 
> Intuitively I'm not convinced about the code set of what the user is doing - I'd say that would need
> some review and maybe a reference implementation to see it in action...
Well i got this types not from the ceiling.
http://www.xmpp.org/extensions/xep-0085.html#bizrules

This works in jabber for years and IMHO it's nice as it already is.

Maybe code shouldnt be a number, maybe it should be a string like "gone".

> Also, this should clearly go as an extension, not part of BASE. It wouldn't even have to be present
> in the SUP since it doesn't require anything as far as hub-client comms go...
Well... may be if it (well be) put in SUP than client may make feature broadcast. This will generate less traffic.