-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File forwarding #50
base: master
Are you sure you want to change the base?
File forwarding #50
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -56,16 +56,27 @@ public static async Task LookupAndSendAsync(SocketGuild guild, ShardedCommandCon | |
return; | ||
} | ||
|
||
if(!IncrementAndCheckMessageLimit.Perform(dbGuild, db)) | ||
if (!IncrementAndCheckMessageLimit.Perform(dbGuild, db)) | ||
{ | ||
await Send.SendErrorWithDeleteReaction(context, "This server has reached its limit of 50 messages for the month. To lift this limit, ask an admin or moderator to upgrade your server to Voltaire Pro. (This can be done via the `!volt pro` command.)"); | ||
return; | ||
} | ||
|
||
var prefix = PrefixHelper.ComputePrefix(context, dbGuild); | ||
var channel = candidateChannels.OrderBy(x => x.Name.Length).First(); | ||
var messageFunction = Send.SendMessageToChannel(channel, replyable, context, dbGuild.UseEmbed); | ||
await messageFunction(prefix, message); | ||
if (context.Message.Attachments.Any()) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would it be possible to do this check and the iteration inside of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You're right that this would be preferable, and it was in fact how I did it initially. It worked fine if a message had a single attachment, but when there were multiple, I noticed that the whole There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Right - could we, for example, return a function that returns that last IUserMessage? Or an array of them? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. as they are awaited inside of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah - the caller is what is doing the awaiting, but I think all of the callers are essentially just awaiting the returned message. We may have to alter the inner workings, but we should be able to have this thing await the returned function and have it receive the result of sending the last message, I think. I'm happy to take a whack at this at this week some point 🙂. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd appreciate that, I'm struggling a little to get my head around async, hence the current state of my changes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, one more issue with just returning the last message; |
||
{ | ||
for (int attachmentIndex = 0; attachmentIndex < context.Message.Attachments.Count; attachmentIndex++) | ||
{ | ||
var messageFunction = Send.SendMessageToChannel(channel, replyable, context, dbGuild.UseEmbed, attachmentIndex); | ||
await messageFunction(prefix, message); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If a message is sent with the attchments, does the message end up being sent multiple times? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This was the case until I added the ternary operations in the SendFileAsync lines. |
||
} | ||
} | ||
else | ||
{ | ||
var messageFunction = Send.SendMessageToChannel(channel, replyable, context, dbGuild.UseEmbed); | ||
await messageFunction(prefix, message); | ||
} | ||
await Send.SendSentEmote(context); | ||
return; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(to continue my previous comment on shifting the check into this function)
If we can do the logic here - I think the goal would be to abstract the check for the existence of files to the top of this function, and leave the branching below agnostic. You may need to add another layer of abstraction, but the branching below shouldn't need to occur in multiple places.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As it is, there are 4 conditions that change the text that is passed along into the message. Adding the attachment check makes a total of 8 options.
Instead of doing the attachments check before this and branching before the text has been finalised, it might be better to use the 4 branches to generate the text and then pass along the resulting message text into another function, which can then determine what to do about attachments, with the text just being 1 input argument. This function would return a
Task<IUserMessage>
back to theSend.SendMessageToChannel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - I'm fine with either option. I think it would need to do something like that, in fact. Some way to capture which message function should be used. This could be another function that is called which wraps
SendMessageAsync
, or a function which is always called by the returned function.