关于加载所有子文件的可扩展子文件的查询
可扩展子文件与 loadall 子文件几乎相同，两者的缓冲区限制都是 9999。唯一的区别是在可扩展的情况下，我们必须处理向下翻页的情况。
我的疑问是，如果它们几乎相同，那么使用可扩展子文件相对于 loadall 子文件有什么优势？
The expandable subfile is pretty much same as the loadall subfile, both having a buffer limit of 9999. The only difference being in case of expandable we have to take care of the page down.
My query is if both of them are nearly same then what is the advantage of using an expandable subfile over a loadall subfile?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当应用程序处理请求时，屏幕显示得更快。无需等到所有记录加载完毕，然后屏幕就会发送到显示器。一页（又名 13 条记录，±）加载速度非常快，因此即使向下滚动也只是稍微慢一些。
机器越旧，效果越明显。
The screen is displayed faster when a request is processed by the application. No need to wait until all records are loaded and then the screen will be sent to the display. One page (aka 13 records, ±) are loaded very quickly, so even scrolling down is just minimally slower.
The older the machine, the more apparent the effect.
回到过去，使用较旧的硬件，可能通过慢速通信链路与远程终端通信，可扩展子文件非常有意义。
您仅根据需要发送页面，与一次一页的子文件相比，您仅发送一次。
如今，对它们的需求已经很少了。特别是如果您实际上并不是在与 5250 终端通话。即使您没有使用 GUI 界面工具集，现代 5250 模拟器也支持一些 GUI 元素，例如单选按钮和 滚动条。
鉴于我们使用 Profound UI，我的偏好是尽可能加载所有子文件。可能会向用户反馈有超过 9999 条记录可用，并且需要包含更多过滤。
Back in the day with older hardware, possibly talking to remote terminals over a slow comm link, expandable subfiles made a lot of sense.
You're only sending pages as needed, and compared to a page-at-a-time subfile, you're only sending them once.
Nowadays, there's very little need for them. Especially if you're not actually talking to a 5250 terminal. Even if you're not using a GUI interface toolset, modern 5250 emulators support some GUI elements such as radio buttons and scroll bars.
My preference, given that we use Profound UI, is to do a load all subfile as much as possible. Possibly with feedback to the user that more than 9999 records are available and that they need to include more filtering.