给精易项目部开发的【扩展界面支持库一Ex】一个建议

美夜赤月

置表项背景颜色
取表项背景颜色
置表项文本颜色
取表项文本颜色
清除表项背景颜色
清除表项文本颜色

这几个命令本来论坛上就有可以实现类似功能的模块源码，你们却为了让这些功能收费，强制让你们的子类化接管，从而导致可用的模块功能失效。
这样的话，你们会让本来就用模块来做超列表颜色的软件全部失效。这样做是否有失大雅？
支持库某些功能收费固然是支持的，因为这是认可开发者的劳动能力的行为，但是本来就有免费的模块源码且不用支持库的功能为什么要强制子类化接管让模块功能失效呢？
因为某些大型的商业软件超列表的颜色渲染是必不可少的，但是居然该支持库做到了兼容原支持库且不做任何改动就能编译出来程序，那么久应该让用户原先的模块功能正常。
你们这样做，就会让用户改动很多地方的代码或者让用户出现不可调试的BUG，毕竟该支持库本身没有源码给用户修改以及调试。

以上是我个人的看法和建议。

@项目部006 @精易客服

oldghost

有点恶意竟争的味道，支持！

福仔

美夜赤月 发表于 2023-2-23 22:26
对的，如果不使用CallWindowProc返回的话模块功能是可以正常的，但是这样就会导致要修改模块里面的代码， ...

支持库也没法判断是否有谁处理了NM_CUSTOMDRAW通知消息
因为得到的就是那个结构, 如果模块处理完之后还调用原来的处理过程, 那就只能表示模块没处理完毕, 或者没处理
支持库得到的也是那个结构, 没有哪个标志能知道有谁处理了这个消息

美夜赤月

福仔 发表于 2023-2-23 21:13
如果支持库能清空模块设置的颜色, 那就是模块处理后又把消息传递到原函数里了
你要是用模块+支持库的话,  ...

对的，如果不使用CallWindowProc返回的话模块功能是可以正常的，但是这样就会导致要修改模块里面的代码，当然，如果有模块源码的情况下，把CallWindowProc的返回改成直接返回0，然后让支持库的子类化返回也是可行的，但是扩展支持库既然做到了兼容原支持库能不改动超列表代码的情况下能直接编译，那么就要考虑到这类的情况，如果内部做个是否调用了收费指令的判断来决定子类化内部需要开启哪些功能是最好的。毕竟有大部分人很可能直接就拿现成品的模块来写自己的程序。（我个人一直不推荐直接用产品模块来写自己的程序，这样不好排查跟修改BUG）

福仔

美夜赤月 发表于 2023-2-23 19:18
模块处理颜色后肯定是返回了，但是支持库会清空模块处理后的类数据。所以就会导致颜色出现不显示的情况， ...

如果支持库能清空模块设置的颜色, 那就是模块处理后又把消息传递到原函数里了
你要是用模块+支持库的话, 那模块处理后就返回, 不要把消息传递到原函数里
因为模块是后子类化的, 所以是先处理消息, 如果处理后直接返回, 不把消息传递到原函数的话, 支持库就不会收到这个消息, 这样支持库就没法改模块设置的信息

美夜赤月

冰点 发表于 2023-2-23 08:33
这绝不是有意为知，只是支持库内部要实现一套，所以才接管子类化， 而且也未对其他已有的模块功能进行测试 ...

这个我知道不是有意为之，建议就是让收费指令与模块兼容一下，如果调用到了支持库的收费指令但是是未付费用户则无法调用该命令，除非是依赖性的调用支持库收费指令，否则的话还是不要让原有的模块指令失效。不然体验效果会大打折扣。

美夜赤月

福仔 发表于 2023-2-23 10:12
子类化哪有什么强制与不强制的说法，支持库实现的很多功能必须通过子类化实现，颜色这一块全部都是处理nm_c ...

模块处理颜色后肯定是返回了，但是支持库会清空模块处理后的类数据。所以就会导致颜色出现不显示的情况，这种情况，可以在支持库的命令里判断是否调用该命令来实现子类化内部需不需要处理颜色的类数据。但是支持库没有这么做。

福仔

子类化哪有什么强制与不强制的说法，支持库实现的很多功能必须通过子类化实现，颜色这一块全部都是处理nm_customdraw
支持库先加载，先子类化，模块后加载，模块肯定是后子类化
如果模块处理颜色后就返回，不把消息传递到原函数里，那支持库颜色设置相关命令全都无效
你要是模块处理后不返回，那消息肯定会传递到支持库里，支持库肯定会自行处理，支持库处理后肯定会覆盖模块设置过的数据，因为都是处理同一个消息

sinewtec

奔过几次还是用回原来的！

大司命

你要看下模块实现是用A版的还是W版的！现在这个支持库用的是W版的，所以模块里你也要用W版的去操作！

冰点

这绝不是有意为知，只是支持库内部要实现一套，所以才接管子类化， 而且也未对其他已有的模块功能进行测试。

我这边会跟进了解一下

感谢大佬建议。