@RubberDuck what if I tell you that there's a feature that displays a dockable treeview showing all opened VBProjects, with all their modules and members.. and that you can use that tree to navigate anywhere?
still working on a few little stupid bugs though, but..
@RubberDuck this might have something to do with it:
public abstract class DockablePresenterBase
{
public const string DockableWindowHostProgId = "Rubberduck.DockableWindowHost";
public const string DockableWindowHostClassId = "9CF1392A-2DC9-48A6-AC0B-E601A9802608";
[ComVisible(true)]
[Guid(ClassId)]
[ProgId(ProgId)]
public partial class DockableWindowHost : UserControl
{
public const string ClassId = "9CF1392A-2DC9-48A6-AC0B-E601A9802608";
public const string ProgId = "Rubberduck.UI.DockableWindowHost";
hmm.. now I wonder which ProgId I have the class registered as
oh look at that... I can bring up the ToDoItems window, and then bring up the CodeExplorer; then I give focus to the ToDoItems window, and when I try to bring up the TestExplorer, VBE gives the focus to... guess!
> GuidPosition (String type): a unique GUID that identifies the toolwindow. Visual Studio uses this identifier to persist the size and position of the toolwindow. So, each toolwindow should have a different GUID
// Get if the toolwindow was visible when the add-in was unloaded last time to show it
registryKey = Microsoft.Win32.Registry.CurrentUser.OpenSubKey(@"Software\MyToolWindow");
if (registryKey != null)
{
if ((int)registryKey.GetValue("MyToolwindowVisible") == TOOLWINDOW_VISIBLE)
{
ShowToolWindow();
}
registryKey.Close();
}
definitely looks like each toolwindow needs its own GUID
> A GUID to uniquely identify the toolWindow. The VBA editor uses this GUID to store information specific to each toolwindow, such as its size or position.
(reading)
@RubberDuck fixed. The GUID you need to pass is that of the user control, not that of the WindowHost
so I've created this interface:
[ComVisible(false)]
public interface IDockableUserControl
{
/// <summary>
/// Gets a string representing the qualified name of the registered class.
/// </summary>
string ProgId { get; }
/// <summary>
/// Gets a string containing the GUID with which the class is registered.
/// </summary>
string ClassId { get; }
/// <summary>
/// Gets a string containing the caption of the toolwindow.
/// </summary>
> Okay, so just how the hell do we find out what kind of procedure we’re working with? How do we find out whether we’re dealing with a Property or a Subroutine?
> That’s right. procKind is an Out parameter. It gets passed by reference. So where all of the other “Proc” properties of a CodeModule need to know what kind of procedure they’re working with, ProcOfLine is the one that actually returns it.
I am seriously stumped as I can't find anything on late binding an array in VBA. Is this even possible? If yes, how? If not - why?
Note: I don't mind if it's possible using a native .Net/C# types like
Dim o as Object
set o = CreateObject("System.Array")
Even though the System.Array is COM vi...
> SELECT CASE WHEN p.DateEstimatedDesignComplete <= GETDATE() THEN 'PastDueProjects' WHEN p.DateEstimatedDesignComplete <= dateadd(week, 1, dateadd(d, -((datepart(weekday, getdate()) + 1 + @@DATEFIRST) % 7), getdate())) THEN 'Due1Week' WHEN p.DateEstimatedDesignComplete <= dateadd(week, 2, dateadd(d, -((datepart(weekday, getdate()) + 1 + @@DATEFIRST) % 7), getdate())) THEN 'Due2Week'
and I want it to check, inclusively, if a given date in the query (the p.DateEstimatedDesignComplete) is within the Friday of weeks, to figure out how many weeks out it's "due"
But I don't know how to make it "inclusive" of the current friday, it always pushes that to the next week
> As for the code tree, we can release without it and provide a pre-release version with it. More eyes on may help find any issues with the parser. Thoughts?
I don't understand, the code tree / code explorer is in the master branch and working
> I don't think the parser is production-ready - examination of the Code Explorer with complex code reveals some occasional weirdness that will need to be addressed before a release, or be documented as a known issue.
@RubberDuck it's less obvious now that I've changed the node tooltip to show the line number, but if you make it display the node type instead, you'll see some methods with a tooltip that says "DoLoopBlockNode" - the parser needs to be fixed, not the Code Explorer ;)
* provided that there are While loops in that method
This is for SQL Server 2008. To use in 2005, just change the date fields to your preference for datetime to date conversions. It also assumes you are not changing the default week begin value.
DECLARE @PassedDate date = '5/21/2011';
SELECT DATEADD(DAY,(CASE DATEPART(DW,@PassedDate) WHEN 7 THEN 6...
@Mat'sMug Right, so by proxy, the Code Explorer isn't ready until the parser is.
So, we create a release where "All these things work." and another where "Hey, the code explorer kinda works, and you can use it, but we know it only kinda works right now."
Private Function GenerateInsertStatement(ByVal value As FiscalCalendarDate) As String
Dim result As String
With value
result = Framework.Strings.Format("INSERT INTO dwd.FiscalCalendars (_DateInserted,CalendarDate,CalendarDayOfWeek,CalendarDayOfMonth,CalendarDayOfYear,CalendarWeekOfMonth,CalendarWeekOfYear,CalendarMonthOfYear,CalendarYear," & _
"FiscalDayOfWeek,FiscalDayOfMonth,FiscalDayOfQuarter,FiscalDayOfYear,FiscalWeekOfMonth,FiscalWeekOfQuarter,FiscalWeekOfYear,FiscalMonthOfQuarter,FiscalMonthOfYear,FiscalQuarterOfYear,FiscalYear,Holiday…
I don't want to imagine what it would look like with plain vanilla VBA string concatenations
@vba4all it's a great solution. If you feel bad then write a class wrapper for it to make usage easier or do something to improve it. But you really shouldn't be feeling bad about it.
Public Property Get CalendarDate() As Date
CalendarDate = this.CalendarDate
End Property
Public Property Let CalendarDate(ByVal value As Date)
this.CalendarDate = value
End Property
Public Property Get CalendarDayOfWeek() As Integer
CalendarDayOfWeek = DatePart("w", this.CalendarDate)
End Property
Public Property Get CalendarDayOfMonth() As Integer
CalendarDayOfMonth = DatePart("d", this.CalendarDate)
End Property
Public Property Get CalendarDayOfYear() As Integer
CalendarDayOfYear = DatePart("y", this.CalendarDate)
well, sort of
@enderland oh... lol, I'm working on a VBA macro to generate an INSERT script for my dwd.FiscalCalendars table
Reading about the Procedure/Module/Project/Global scopes right now. Does that type of scoping apply to many programming languages or is that specific to VBA?
What's a real world example where one would want to make a variable Public as opposed to Private? Asking innocently, I understand the idea but can't make it line up with anything concrete...
@Phrancis Generally making variables Public is a good indication you are making a hack/doing something which is going to be difficult to troubleshoot in the future
Stop confusing the poor guy. It's like Hungarian notation. Yes, there's a right way to do it, but for a beginner( no offense meant @Phrancis) it's easier to just say "Don't do it."
I need to generate a T-SQL script for loading data into this table:
create table dwd.FiscalCalendars (
_Id int not null identity(1,1)
,_DateInserted datetime not null
,_DateUpdated datetime null
,CalendarDate date not null
,CalendarDayOfWeek int not null
,CalendarDayOfMo...
I am seriously stumped as I can't find anything on late binding an array in VBA. Is this even possible? If yes, how? If not - why?
Note: I don't mind if it's possible using a native .Net/C# types like
Dim o as Object
set o = CreateObject("System.Array")
Even though the System.Array is COM vi...
I need to generate a T-SQL script for loading data into this table:
create table dwd.FiscalCalendars (
_Id int not null identity(1,1)
,_DateInserted datetime not null
,_DateUpdated datetime null
,CalendarDate date not null
,CalendarDayOfWeek int not null
,CalendarDayOfMo...
VBA Rubberducking
VBA Rubberducking