|
Bob,
Assuming your using VB.NET 2005.
There are tons of techniques. Using a MDI approach would be easy also. You could define a single class for controlling which one is currently visible.
Another approach, is to use multiple Panels on the same form. Hiding each one but the current one.
You can optionally use a Tab control, only showing a single tab at a time.
Of course, I'm not clear on how MS Money does it. But there are also docking controls like the split panel control.
If you are not using VB.NET 2005, instead you are using VB6. Then you'll have to do a little bit more coding, and some of the controls listed are not available in VB6.
In VB6, you can use multiple Panel controls. Set the Left Property of the ones you want to hide to -10000. This moves it completely off the form. You can swap them in and out by setting their corresponding Left property to the setting that makes them visible.
Although, I've created some fairly complex applications in VB6. I've been using VB.NET for quite sometime now.
Hope this helps!
~ CodeDoctor ~
|
|
|
|
|
hai,
i want to develope asp.net web project.any tools to design the project specs,Preparing DSD.
Thanks and regards,
surendra
|
|
|
|
|
I'm considering embarking on my first C# adventure by way of creating an inventory system for the electrical power industry. I spent much of tonight trying to lay out an object heirarchy and only ended up confusing myself.
The top level class, InventoryItem, is a no-brainer. The next level is almost as simple - Overhead, Underground, Substation, Multi-use. Then it starts to get complicated. For example, a simple disconnect comes in multiple flavors - solid blade or fused, 15kV or 25kV, 200A or 600A, load-breaking or non-load-breaking, ganged or single-phase, 1-, 2, or 3-pole. That I can deal with by creating subclasses. But each type is made by multiple manufacturers, and sold by multiple vendors, each with its own pricing. No one vendor sells all products from a single manufacturer, and no manufacturer sells all products through one vendor. Each vendor's pricing is different, even for the same item from the same manufacturer, and prices change weekly. To make matters more interesting, several manufacturers make the same item, interchangeable at will, and we stock equivalent parts from multiple manufacturers and vendors as one SKU.
The goal here is to keep track of inventory items at the vendor/manufacturer level, but accumulate costs at the SKU level to be used for estimating future jobs.
Can someone among you geniuses suggest a logical class heirachy for this mess? I think the coding will be fairly straightforward, but the difference between a raging success and a dismal failure lies in getting the structure right from the get-go. Thanks, in advance, if you have a useful suggestion.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
|
|
|
|
|
Why are you hard-coding the items? Wouldn't it be better to create a database?
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
What makes you think he is not using database? Mapping DB records on classes is nothing strange...
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
|
|
|
|
|
Roger Wright wrote: Can someone among you geniuses suggest a logical class heirachy for this mess?
It would take more than a "genius" to do so because there is no logical hierarchical model for something that isn't, inherently, hierarchical. It isn't a "mess"; it's just not hierarchical.
|
|
|
|
|
- Do you have an existing GIS ?
- Do you model/maintain phase info ?
- Do you model secondary runs from transformer to meter ?
- Do you model transmission (to subs)
(ok, only effect the fields, but i'm curious  )
You will not want to break down the tables or class' beyond the type level.
e.g.
InvItem
|__ Fuse
|__ Transformer
| |__ 1 phase (optional)
| |__ 3 phase ('')
|__ Capacitor
|__ Switch
|__ ...
Some of the elec inv systems i've seen didn't even maintained separate tables for facility types.
It was one big table with InvId, vendor, manuf., manuf sku, price, price date, (elec util) sku, description, ...
Decription held "40A fuse", ...
You will make life easier if you match the facility table break down that you use in you GIS (assuming you have a GIS, assuming you don't want to throw all inv items into one table).
The inv system doesn't (generally) care about details like phases, amps, voltage, ... that should all be in the GIS table (that's why you can throw all that info into a inv desc field).
The GIS table should just contain the InvId (unique for vendor/manuf/manuf sku) and optionally the (elec util) SKU (read-only in GIS, to validate InvId), plus the detail info like phases, voltage, circuit, ohug, state, ... .
Of course going to the next level, you break out the detail info in the inv tables, and have the inv system tied to the GIS so that the GIS placement routines use the inv system to display validation tables for the digitizer to select from (then pull phase, ... from inv tables and copy into gis fields).
Once you have all this info you will want to gen std drawings e.g. std pole, std gang-switch (attachment for a pole), ... . This system can then be used by the eng to do quick designs and part/cost estimates. A full system includes things like how many man hrs it takes to install each part as well.
If i were coming to you guys as a consultant the system i would propose would depend LOT on what you already have (what GIS - what schema, do std drawing exist - what format, current inv data system/format, ...) ... and of course how much money you want to spend .
...cmk
Save the whales - collect the whole set
|
|
|
|
|
cmk wrote: Do you have an existing GIS ?
Yup, and we paid a bundle to collect it. Unfortunately, now that I've gained more understanding of the GIS schema the consultant created, I see that it was a crappy job, full of unused fields, duplicates, and unnecessary data.
cmk wrote: Do you model/maintain phase info ?
- Do you model secondary runs from transformer to meter ?
Not yet, though we collected conductor/structure data with the intent of one day modelling it. Ideally, the GIS geodatabase would be the ideal place to store details about structure and implementation, and a separate db would contain just stock and reordering info. The more important task is probably to clean up the mess in the GIS schema, but the priority from a business standpoint is to track and maintain adequate stocks of spare parts - two very different jobs.
The info in the GIS system should probably be treated as a super-inventory, with assemblies tracked as finished goods created from parts drawn from stores and tracked by the general inventory. We use RUS standard structures, with minor variations, for most of our network, and I have the standard drawings in AutoCAD format. Since the new AutoCAD 2007 adds the ability to link the data fields in a table to an external database, it should be fairly straightforward to generate up-to-date costs at the structure level for future construction using average costs from the inventory db. That would also, when coupled with accurate GIS data, give us current replacement costs for installed plant.
Hmmm... You've given me much to rethink - Thanks!
"...a photo album is like Life, but flat and stuck to pages." - Shog9
|
|
|
|
|
Roger Wright wrote: full of unused fields, duplicates, and unnecessary data
I've worked with a dozen or so elec utilities, EVERY one had the same issues, as well as unfilled fields - which can be the most frustrating.
Roger Wright wrote: The more important task is probably to clean up the mess in the GIS schema
Another common phrase heard at utilities everyware. 
Roger Wright wrote: should probably be treated as a super-inventory
I view the GIS as the asset management system vs the inventory management system you're developing.
The main problem i've seen with IT systems developed in utilities is one that is forced on management. Usually the initial project is funded by capital funds and can be as big as needed, but after that any further work is funded by the yearly O&M budget which is much smaller. As a result they try to cram everything they can think of in the initial phase. Unfortunately after a year or so, upon reflection, it is obvious that a lot of things could have been done better, but now there are stuck with a bad design that they have to work around for the next 5yrs - at which point they replace the GIS again ... and so the cycle continues.
Roger Wright wrote: standard drawings in AutoCAD format
Also fairly common. As you mentioned it should be fairly easy to link these to a db. What you really want to go for though is having a design interface in the GIS that allows your engineers to place prelim plant and be able to query the standard drawings. This GIS interface would also give the eng the ability to select (by region or piece) the prelim plant and generate a BOM. What i'm trying to point out is that the acad-db combo is just a data source, it's useless on its own, you still need to design/develop the interface to it in a GIS design module. This design interface will likely be (should be) different than that used by the digitizers to place designed plant.
What GIS are you using (ArcInfo, Smallworld, AutoMap, Intergraph, ...) ?
If you have any questions, or want to bounce some ideas around feel free to post them or email me, i find all this stuff fascinating (well i guess i should, it's my job as well ).
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Correct me if I'm wrong, but you are looking to do something like this:
You have a collection of unique InventoryItems.
Each InventoryItem has an SKU associated with it.
You have a collection of manufacturers
You have a collection of vendors
A manufacturer has a collection of vendors associated with it.
A vendor has a collection of InventoryItems associated with it.
A manufacturer has a collection of InventoryItems associated with it.
The Overhead, Underground, etc. are just types of InventoryItems.
If this summary is correct, then we can go from there.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
That's about as far as I've got with it, and it's what I'm used to seeing in retail. But what cmk, above, suggests makes sense. I'm going to play with that approach for a bit and see where it takes me.
"...a photo album is like Life, but flat and stuck to pages." - Shog9
|
|
|
|
|
Hi all,
i m developing a ndis miniport driver.
in my miniport driver OS is able to enter into Driverentry function automatically after regtistration of the adapter in NSB_Init function.
in DriverEntry's initialize function, i activate a timer which reads from the hardware.
now this timer is able to read the data from hardware but i am nt able to bind it to the TCP/IP stuff.
i think there should be some binding issue.
i tried with "NdisBindProtocolsToAdapter", but it is not able to bind it
when i called "NdisGetAdapterNames" after that, i am able to get my adapter's name in that.
so if i say basic problem is that i am able to get the data in MAC layer but i am not able to bind it to tthe IP layer.
can you guys solve this?
if yes then kindly give me some clue about it.
thanks in advance.
Hardik 
|
|
|
|
|
Errm. This is the wrong forum. It's about application design and architecture.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Hello All
I need to send email using Binary SOAP. I used DIME but i realised that
it only send attachment by binary soap, though my requirement is that i
need to send attachment AND the enter email attributes(user's and receipient
email, message, subject line). can anyone tell me how can i have this done and
which technique to use for sending all these attributes using Binary SOAP.
Ankit Sharma
|
|
|
|
|
Intro:
I am trying to design a triggered execution system where the developer implements trigger-modules that is loaded runtime and fires an event that the system can subscribe to.
The user uses an interface to the system where he can create new instances of triggers and specify the needed input to the selected trigger.
Example:
The developer implements a File Change trigger, that fires an event whenenver a user specified file changes.
This would require some input Fileobject and the possibility to save the last run date for the trigger.
When the user chooses the File Change trigger in the interface he should be prompted to input a file, which is then stored in the instance of the File Change trigger.
2nd Example:
A Calendar trigger. The user should be prompted to select a date in a calendar+ a time and the trigger would then fire the event on the specific datetime.
Question:
The interface is a thin client and does not know anything about the modules in compile time except the interface. So the question is - how do I design the module interfaces so the interface knows what information to ask the user for (and how) and insert the user input into the instance of the loaded trigger?
I have played around with HTML contained in the module, presenting it in the interface and catching the user input.... But so far not in a satisfactory way
(I hope this summary made sense )
Thanks in advance...
|
|
|
|
|
This article might be of some help. Razor Framework.[^]
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
I am trying to write a layered app in vb 2005 .NET
I think on a 2 physical levels/tiers: host with a DB, and client (desktop), both not interconnected (except for internet)
Host: will contain the DB (SQLServer) , the Data Access Layer DAL, and a Web Service layer, WS_CH
desktop, will contain the application (winforms), and Business Logic layer BLL. The BLL will call the (remote) WS_CH, this will call the DAL and this will attack the DB. OK.
I will use a Data Transfer Object DTO to pass data up and down all the stream, from the UI to the DB and back. This DTO can be an untyped dataset, in which case all the assemblies involved (in fact, all I mentioned) will contain a reference to System.Data.
But.... what if I want the DTO to be a custom class, living in a independent assembly, and possibly hosted in the client. How will the host receive and handle a reference to that (remote) object.
Have I to place the DTO in the host (because from the client I know the URL and then I can reference it)?. If not, i suspect I have to use remoting technology, or activator, or reflection, or the new WCF in 3.0,... but I cannot find my way to that.....
Any hint, please? thx
|
|
|
|
|
This thread might help to get you started:
Clickety[^]
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
thx, that thread deals on dataset versus other structures as Data Transfer Objects, and this is OK, but if the DAL in a remote host has to deal, say, with a typed dataset or a custom class or custom collection defined in the desktop (in an assembly who seats in a desktop, I mean), how can the DAL (in the host) get a reference to that????
|
|
|
|
|
Actually, the thread deals with defining the structure of the class in the datalayer (I know because I wrote that thread as well). Once the structure is defined in the DAL, then it can be made available across all the tiers. So, the DAL can populate the collection, and new entries can be added in the business layer and saved back via the DAL.
So, if you reverse your thinking, you start with the entity in the DAL and then this gets exposed to the business layer (and on into the presentation layer).
The beauty about this approach is that you remove the need to reference things such as System.Data in the front end, and as I stated in that thread you can expose this to other programming environments as well.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
thx, letting the DTO live in the host, together with the DAL "it gets exposed to the BL and presentation layer"... but, how, if DAL/DTO and BL/PL are in different computers, only visible through internet?
thx
|
|
|
|
|
If you are using a webservice, the definition of the class (well a proxy version), will be added to the business layer when you add in a web-reference. This means that you can pass this back and forwards without worrying about it.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Hiya,
Not sure if you're still looking at this, but I came across a similiar problem where in the BLL and UI layers I had my own data objects that were hosted in the client or a webservice. Communication from the BLL to the DAL is remoting.
I didn't want the DAL to have any knowledge of these objects because these objects were "plugins" and the DAL could not possibly be able to reference the objects.
What I did was implement functionality to disassemble custom classes (in the BLL tier) into a generic object which was then passed into the DAL. All my custom classes inherit from a general object providing methods and properties to extract the data from the custom class, which helped disassemble the data.
Hope this helps
Cheers,
Ty
|
|
|
|
|
thanks, remoting is the answer I was looking for. Anyway, with framework 3.0 maybe the right way is to use WCF windows communication foundation that seems to combine webservices and remoting in a unified skeleton
thx
|
|
|
|
|
Hi All
Can someone share with me the architecture or Design for any large localization Web project which primarily publishes the content , I mean
something like MSDN help being localized to different languages.
Please suggest me how I can approach for localizing MSDN if I have all my resource files in XML format.
The guy in China should see in Chinese and in US in English , also
1)There are some security implications to be added like all content should not be seen in a particular page outside USA, only specific sections pertaining to that country should be seen in that localized language.
2)Can manifest of an assembly be useful in doing a dynamic way of localizing.
Any reference or suggestions with the pros and cons of the architecture is highly appreciated as this is a bit urgent need.
Rgds
Ind_Coder
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
