I am working through the later part of the sample in chapter 7, page 199, and in the cmdAdd_Click event routine you are assigning the objShopList.coffeeShopID = coffeeShopID in the ShopList.ascx uc.
My question is, where is coffeeShopID declared on the RHS of equation? It's not within the user control and is the key id input for a new CoffeeShopListingInfo record, which I would think would be a null input.
Has anyone run into this issue when working through the sample? Any help is very appreciated!
I do not have the module currently installed to test but when adding a new coffee shop it is likely set when the record is saved to the database as a result of the identity column.
HTH
Thank you for your input. I believe I found the problem. I went ahead with the sample project and on the second ascx control, EditShopList, there is a variable declared:
Dim coffeeShopID as Integer = -1
This variable wasn't declared in the first ascx control, so there "may" be an accidental omission. This is really a great book for DNN 3.0. Egan writes very well and I would recommend this book for anyone looking to get more familiar with DNN, both from
a admin perspective as well as from a developer perspective.
I'm trying to follow through chapter 7 in this book though I am not actually creating a coffee shop but trying to apply it all to my own project.
When I get to creating the SqlDataProvider class and try to
Inherits DataProvider
I always get the error "Type DataProvider is not defined." This whether I precede with namespace or not. I've gone through every step twice and can't see where I'm missing anything.
Just make sure a Project reference to your UI and BLL project is added to the references in the SqlDataProvider project. It may not pick up the reference until you successfully compile the UI and BLL project. I generally compile before I start hacking at
it, so I usually don't get this. I have seen it though. Do you have a
successful build of the UI and BLL DLL?
I will often look at other projects to see how they are laid out, such as the DotNetNuke.HTML project and the corresponding DotNetNuke.HTML.SqlDataProder project - which is the project level you are working at. In the SqlDataProvider project you will see
that the DotNetNuke.HTML project (UI) is a referenced project. If you look at the HTML UI project you will find the DataProvider.vb class that your application is looking for (not this specific class rather the DataProvider.vb class for your UI). So as Wallew
pointed out, make sure you have this project referenced and you should be OK.
Make certain to download the source code from
http://www.packtpub.com/support/book/dotnetnuke as some of the code printed in the book for Chapter 7 is in abbreviated form. I also encountered some missing event handlers and other issues but will need to check with publisher just in case the source has
been updated since I originally downloaded it.
I have sent details of the issues I found getting the module to work to the publisher for review. If you require additional information a copy of the file in MS Word format is available by clicking
here. Please note the file is approx 500K due to some embedded images and it is in a protected area that requires registration.
Yes, I found a few things, some which might be considered errata.
The book doesn't indicate that it is necessary to add a reference to Microsoft.ApplicationBlocks.Data, and this one must be located by browsing.
The book doesn't indicate that it is necessary to add a reference to the main project in the SqlDataProvider project.
As suggested above, comparing with other projects helps to discover these things.
Also, I have a general confusion about
project name
folder name
assembly name
namespace
and how these things are/are not related, which I had to resolve even after getting the references squared away. I did get it resolved but don't exactly understand yet how what I ended up doing is different than what I was doing when it didn't work. Always
hated that!
But that's not an issue with the book - it's my own learning curve.
I'm a bit further down the road now and am looking forward to my next problem.
There is a note to pull in a few imports and a comment about the Microsoft.ApplicationBlocks.Data reference on pg. 179. I think I just knew to add the reference from the Desktop Module from viewing other relationships in similar projects, but could see
how this would help.
I can give a shot at trying to clarify the "names" you are referring to:
In VS.NET there are two main file types used to group classes and resources. The first is the Project, which you referred to above and the second is the Solution (*.sln). A project can contain classes (*.vb), asp.net pages (aspx), user controls (ascx),
and other files. A project file can be compiled to IL or assemblies with an EXE or DLL extention. Most applications are made up of many projects, especially if it is a n-tier application or written in more than one programming language. You'll often want
to create one or more groupings of these projects and you do so in a Solution. A Solution can contain one or more projects written in one or more languages. Depending on what your intention are when running the code using VS.NET you may have more than one
solution, each with a unique sub-set of Projects (such as DNN 3 developers have done as seen in the Solutions folder under the DNN root directory).
Folder name is the same name as the Windows Explorer named folder. When creating folders within your project your folders will assume the relative path of your project's folder layout, with the project being the base directory. So for a folder "Installation"
added to or off of your project you can expect to find the folder using Windows Explorer under the project folder, c:\DNNFolder\DesktopModules\YourProject\Installation.
An assembly name is the name of the DLL or EXE file that you build in VS.NET. If you use the Company.ProjectName, naming convention, then for a DLL you will most likely see the name as YourCompany.YourProject.DLL. An assembly represents the fundamental
unit of compiled, distributable code.
Where as an assembly represents the unit of compiled, distributable code, a namespace become a part of the compiled assembly and represents a user-defined scope for defining types. Namespaces are used to prevent naming conflicts across assemblies. Although
the "name" given to the assembly can be the same as your namespace, there isn't a direct relationship between them. A namespace could be as arbitrary as you want it to be, but by using meaningful namespaces, espcecially in your modules, you will find it much
easier to access the code you are looking to execute and will help ensure you don't have collison of names across the assemblies you create, and any others that exist in the .NET framework.
JohnVndnBrk
None
0 Points
71 Posts
Building Websites with VB.NET and DNN 3 Question
Apr 01, 2005 02:47 PM|JohnVndnBrk|LINK
Hello:
I am working through the later part of the sample in chapter 7, page 199, and in the cmdAdd_Click event routine you are assigning the objShopList.coffeeShopID = coffeeShopID in the ShopList.ascx uc.
My question is, where is coffeeShopID declared on the RHS of equation? It's not within the user control and is the key id input for a new CoffeeShopListingInfo record, which I would think would be a null input.
Has anyone run into this issue when working through the sample? Any help is very appreciated!
Thanks!
John
mumfie2003
None
0 Points
242 Posts
Re: Building Websites with VB.NET and DNN 3 Question
Apr 01, 2005 05:59 PM|mumfie2003|LINK
HTH
http://www.colin-munford.me.uk
JohnVndnBrk
None
0 Points
71 Posts
Re: Building Websites with VB.NET and DNN 3 Question
Apr 02, 2005 06:24 PM|JohnVndnBrk|LINK
Thank you for your input. I believe I found the problem. I went ahead with the sample project and on the second ascx control, EditShopList, there is a variable declared:
Dim coffeeShopID as Integer = -1
This variable wasn't declared in the first ascx control, so there "may" be an accidental omission. This is really a great book for DNN 3.0. Egan writes very well and I would recommend this book for anyone looking to get more familiar with DNN, both from a admin perspective as well as from a developer perspective.
Thanks![:)]
pmgerholdt
Member
10 Points
244 Posts
Re: Building Websites with VB.NET and DNN 3 Question
Apr 02, 2005 08:18 PM|pmgerholdt|LINK
I'm trying to follow through chapter 7 in this book though I am not actually creating a coffee shop but trying to apply it all to my own project.
When I get to creating the SqlDataProvider class and try to
Inherits DataProvider
I always get the error "Type DataProvider is not defined." This whether I precede with namespace or not. I've gone through every step twice and can't see where I'm missing anything.
Anybody help?
wallew
None
0 Points
251 Posts
Re: Building Websites with VB.NET and DNN 3 Question
Apr 02, 2005 11:43 PM|wallew|LINK
Just make sure a Project reference to your UI and BLL project is added to the references in the SqlDataProvider project. It may not pick up the reference until you successfully compile the UI and BLL project. I generally compile before I start hacking at it, so I usually don't get this. I have seen it though. Do you have a successful build of the UI and BLL DLL?
Wallew
JohnVndnBrk
None
0 Points
71 Posts
Re: Building Websites with VB.NET and DNN 3 Question
Apr 03, 2005 01:33 AM|JohnVndnBrk|LINK
I will often look at other projects to see how they are laid out, such as the DotNetNuke.HTML project and the corresponding DotNetNuke.HTML.SqlDataProder project - which is the project level you are working at. In the SqlDataProvider project you will see that the DotNetNuke.HTML project (UI) is a referenced project. If you look at the HTML UI project you will find the DataProvider.vb class that your application is looking for (not this specific class rather the DataProvider.vb class for your UI). So as Wallew pointed out, make sure you have this project referenced and you should be OK.
mumfie2003
None
0 Points
242 Posts
Re: Building Websites with VB.NET and DNN 3 Question
Apr 03, 2005 03:27 AM|mumfie2003|LINK
http://www.colin-munford.me.uk
mumfie2003
None
0 Points
242 Posts
Re: Building Websites with VB.NET and DNN 3 Question
Apr 03, 2005 10:39 AM|mumfie2003|LINK
I have sent details of the issues I found getting the module to work to the publisher for review. If you require additional information a copy of the file in MS Word format is available by clicking here. Please note the file is approx 500K due to some embedded images and it is in a protected area that requires registration.
http://www.colin-munford.me.uk
pmgerholdt
Member
10 Points
244 Posts
Re: Building Websites with VB.NET and DNN 3 Question
Apr 03, 2005 10:40 AM|pmgerholdt|LINK
Yes, I found a few things, some which might be considered errata.
The book doesn't indicate that it is necessary to add a reference to Microsoft.ApplicationBlocks.Data, and this one must be located by browsing.
The book doesn't indicate that it is necessary to add a reference to the main project in the SqlDataProvider project.
As suggested above, comparing with other projects helps to discover these things.
Also, I have a general confusion about
project name
folder name
assembly name
namespace
and how these things are/are not related, which I had to resolve even after getting the references squared away. I did get it resolved but don't exactly understand yet how what I ended up doing is different than what I was doing when it didn't work. Always hated that!
But that's not an issue with the book - it's my own learning curve.
I'm a bit further down the road now and am looking forward to my next problem.
JohnVndnBrk
None
0 Points
71 Posts
Re: Building Websites with VB.NET and DNN 3 Question
Apr 04, 2005 06:55 PM|JohnVndnBrk|LINK
There is a note to pull in a few imports and a comment about the Microsoft.ApplicationBlocks.Data reference on pg. 179. I think I just knew to add the reference from the Desktop Module from viewing other relationships in similar projects, but could see how this would help.
I can give a shot at trying to clarify the "names" you are referring to:
In VS.NET there are two main file types used to group classes and resources. The first is the Project, which you referred to above and the second is the Solution (*.sln). A project can contain classes (*.vb), asp.net pages (aspx), user controls (ascx), and other files. A project file can be compiled to IL or assemblies with an EXE or DLL extention. Most applications are made up of many projects, especially if it is a n-tier application or written in more than one programming language. You'll often want to create one or more groupings of these projects and you do so in a Solution. A Solution can contain one or more projects written in one or more languages. Depending on what your intention are when running the code using VS.NET you may have more than one solution, each with a unique sub-set of Projects (such as DNN 3 developers have done as seen in the Solutions folder under the DNN root directory).
Folder name is the same name as the Windows Explorer named folder. When creating folders within your project your folders will assume the relative path of your project's folder layout, with the project being the base directory. So for a folder "Installation" added to or off of your project you can expect to find the folder using Windows Explorer under the project folder, c:\DNNFolder\DesktopModules\YourProject\Installation.
An assembly name is the name of the DLL or EXE file that you build in VS.NET. If you use the Company.ProjectName, naming convention, then for a DLL you will most likely see the name as YourCompany.YourProject.DLL. An assembly represents the fundamental unit of compiled, distributable code.
Where as an assembly represents the unit of compiled, distributable code, a namespace become a part of the compiled assembly and represents a user-defined scope for defining types. Namespaces are used to prevent naming conflicts across assemblies. Although the "name" given to the assembly can be the same as your namespace, there isn't a direct relationship between them. A namespace could be as arbitrary as you want it to be, but by using meaningful namespaces, espcecially in your modules, you will find it much easier to access the code you are looking to execute and will help ensure you don't have collison of names across the assemblies you create, and any others that exist in the .NET framework.
Hope that helps!